> On Jan 24, 2017, at 8:56 PM, Chris Lattner <sa...@nondot.org> wrote:
>
>
>> On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev
>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>
>> I’m sending out a proposal for fundamentally changing SIL. This work feeds
>> into generic code optimization, resilience, semantic ARC, and SIL ownership.
>> This was discussed at length back in October—some info went out on
>> swift-dev—but I realized there hasn’t been a formal proposal. So here it is.
>> I want to make sure enough people have seen this before pushing my PR that
>> puts the infrastructure in place: https://github.com/apple/swift/pull/6922
>> <https://github.com/apple/swift/pull/6922>.
>>
>> Rendered Proposal:
>> https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7'
>> <https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7'>
> This is great Andy, thanks for pushing it forward. One question: are you
> concerned at all that the SSA representation of address only values will make
> it “too easy” for the optimizer to reorder instruction such that a lot more
> temporary values will been needed in lowering?
>
> -Chris
>
That would come about when the program wants to use the same lvalue for
multiple real values. I don't expect many problems with simple opaque types.
The only way to mutate them is either passing them @inout or returning them
@out. We could introduce a copy by sinking a use below one of these calls. But
the uses are also likely to be calls.
It could happen. The typically annoying case with copy coalescing in general is
induction variables that are both modified in the loop and live out of the
loop. I wasn't even able to force a scenario like this with Swift opaque values
that didn't already generate a copy up front.
There's definitely an issue with all the temporaries needed to inject opaque
values into aggregates. Address lowering needs to be smart about this, but I
have a straightforward storage allocation algortihm in mind that should take
care of the expected cases. I'm anxious to try out a prototype and get some
data.
-Andy
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
