[swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

[John McCall]

> On Oct 5, 2016, at 4:48 PM, Michael Gottesman <mgottesman at apple.com> wrote:
>> On Oct 5, 2016, at 4:40 PM, Michael Gottesman via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>>> 
>>> On Oct 4, 2016, at 1:04 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>>> 
>>>> 
>>>> On Sep 30, 2016, at 11:54 PM, Michael Gottesman via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>> 
>>>> The document attached below contains the first "Semantic ARC" mini proposal: the High Level ARC Memory Operations Proposal.
>>>> 
>>>> An html rendered version of this markdown document is available at the following URL:
>>>> 
>>>> https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html <https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html>
>>>> 
>>>> ----
>>>> 
>>>> # Summary
>>>> 
>>>> This document proposes:
>>>> 
>>>> 1. adding the `load_strong`, `store_strong` instructions to SIL. These can only
>>>>    be used with memory locations of `non-trivial` type.
>>> 
>>> I would really like to avoid using the word "strong" here.  Under the current proposal, these instructions will be usable with arbitrary non-trivial types, not just primitive class references.  Even if you think of an aggregate that happens to contain one or more strong references as some sort of aggregate strong reference (which is questionable but not completely absurd), we already have loadable non-strong class references that this operation would be usable with, like native unowned references.  "load_strong %0 : $*@sil_unowned T" as an operation yielding a scalar "@sil_unowned T" is ridiculous, and it will only get more ridiculous when we eventually allow this operation to work with types that are currently address-only, like weak references.
>>> 
>>> Brainstorming:
>>> 
>>> Something like load_copy and store_copy would be a bit unfortunate, since store_copy doesn't actually copy the source operand and we want to have a load_copy [take].
>>> 
>>> load_value and store_value seem excessively generic.  It's not like non-trivial types aren't values.
>>> 
>>> One question that comes to mind: do we actually need new instructions here other than for staging purposes?  We don't actually need new instructions for pseudo-linear SIL to work; we just need to say that we only enforce pseudo-linearity for non-trivial types.
>>> 
>>> If we just want the instruction to be explicit about ownership so that we can easily distinguish these cases, we can make the rule always explicit, e.g.:
>>>   load [take] %0 : $*MyClass
>>>   load [copy] %0 : $*MyClass
>>>   load [trivial] %0 : $*Int
>>> 
>>>   store %0 to [initialization] %1 : $*MyClass
>>>   store %0 to [assignment] %1 : $*MyClass
>>>   store %0 to [trivial] %1 : $*Int
>>> 
>>> John.
>> 
>> The reason why I originally suggested to go the load_strong route is that we already have load_weak, load_unowned instructions. If I could add a load_strong instruction, then it would make sense to assign an engineer to do a pass over all 3 of these instructions and combine them into 1 load instruction. That is, first transform into a form amenable for canonicalization and then canonicalize all at once.
>> 
>> As you pointed out, both load_unowned and load_weak involve representation changes in type (for instance the change of weak pointers to Optional<T>). Such a change would be against the "spirit" of a load instruction to perform such representation changes versus ownership changes.
>> 
>> In terms of the properties that we actually want here, what is important is that we can verify that no non-trivially typed values are loaded in an unsafe unowned manner. That can be done also with ownership flags on load/store.
>> 
>> Does this sound reasonable:
>> 
>> 1. We introduce two enums that define memory ownership changes, one for load and one for store. Both of these enums will contain a [trivial] ownership.
>> 2. We enforce in the verifier that non-trivial types must have a non-trivial ownership modifier on any memory operations that they are involved in.
> 
> Sorry for not being explicit. I will not add new instructions, just modifiers. Assuming that this is agreeable to you, I am going to prepare a quick additional version of the proposal document.

That sounds great, thanks.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161006/583fc3fc/attachment.html>