> On Oct 7, 2016, at 10:08 PM, Michael Gottesman <mgottes...@apple.com> wrote:
>
>>
>> On Oct 7, 2016, at 9:25 PM, Andrew Trick <atr...@apple.com
>> <mailto:atr...@apple.com>> wrote:
>>
>>
>>> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev
>>> <swift-dev@swift.org <mailto:swift-dev@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.
I also want to prove that my understanding of the model is accurate by seeing
everything work with load [copy].
-Andy
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev