> On Oct 7, 2016, at 10:26 PM, Andrew Trick <[email protected]> wrote:
>
>
>> On Oct 7, 2016, at 10:08 PM, Michael Gottesman <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> On Oct 7, 2016, at 9:25 PM, Andrew Trick <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev
>>>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
