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

[Michael Gottesman]

> On Oct 7, 2016, at 10:26 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Oct 7, 2016, at 10:08 PM, Michael Gottesman <mgottesman at apple.com <mailto:mgottesman at apple.com>> wrote:
>> 
>>> 
>>> On Oct 7, 2016, at 9:25 PM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote:
>>> 
>>> 
>>>> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>> 
>>>>> I wonder whether it might make more sense for load [borrow] to be a different instruction.
>>>>> There's a couple reasons for that first.  The first is that it's the only load which introduces
>>>>> a scope, which is a really big difference structurally.  The second is that it's the only load
>>>>> which returns a non-owned value, which will be a typing difference when we record
>>>>> ownership in the type system.
>>>> 
>>>> I am fine with a load_borrow. If this is the only change left that you want can I just send out a proposal with that small change and start implementing. I am nervous about perfection being the enemy of the good (and I want to start implementing this weekend if possible *evil smile*).
>>> 
>>> There’s a lot in the proposal that makes sense to discuss for completeness but isn’t motivated by a particular need. Please separate functionality. We only need load [copy] at first right? When do those need to be promoted to load_borrow?
>> 
>> These are needed for the ARC optimizer to eliminate retain, release operations, i.e. a:
>> 
>> %0 = load [copy] %x_ptr
>> 
>> destroy_value %1
>> 
>> =>
>> 
>> %0 = load [borrow] %x_ptr
>> 
>> borrow_end(%0, %x_ptr)
>> 
>> These constructs will be needed by engineers to update passes like ARC. By implementing such modifiers now, we can begin to implement support in the various passes for these new instructions via sil-opt/etc in parallel to other semantic ARC work.
>> 
>>> load [trivial] is an optimization, so that should follow a functionally complete implementation. 
>> 
>> Yes you are correct that given that we are exploding the load [copy] in the eliminator, the trivial load is not *strictly* needed. But as soon as we start upgrading passes, we are going to want this. Again assuming that parallel work can be done, it makes sense to set the stage for optimizer work that will occur in parallel to further semantic ARC work.
>> 
>>>  load [take] should definitely not exist until there’s some motivation.
>> 
>> If you look at the frontend, there are places where the frontend wants to emit a take. Unless we are willing to use unqualified loads for those cases (which we can not if we are trying to prove that no unqualified loads are emitted by the frontend), then we must have a load [take].
>> 
>> Did I provide the motivation that you requested?
> 
> Yes. My general request is for each commit to be easy to review and the functionality obvious to test. I’m convinced we’ll eventually want the variants. Although I still want to understand better when we need to [take] values out of memory.

Just as a quick example, the API for emitLoad in SILGenFunction:

  ManagedValue emitLoad(SILLocation loc, SILValue addr,
                        const TypeLowering &rvalueTL,
                        SGFContext C, IsTake_t isTake,
                        bool isGuaranteedValid = false);

Notice the IsTake_t parameter. I see that code path used in several locations in SILGenFunction.

> 
> I also want to prove that my understanding of the model is accurate by seeing everything work with load [copy].

I am fine doing everything initially with load [copy] (and when SILGen requires load [take]). The other things can wait until we need them. I just don't want to have to do another proposal at that point ; ).

> 
> -Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161007/bf139a34/attachment.html>