[swift-dev] Proposal: Opaque SIL values

[Andrew Trick]

> On Jan 24, 2017, at 8:56 PM, Chris Lattner <sabre at nondot.org> wrote:
> 
> 
>> On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170124/fe075110/attachment.html>