<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 24, 2017, at 8:56 PM, Chris Lattner <<a href="mailto:sabre@nondot.org" class="">sabre@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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: <a href="https://github.com/apple/swift/pull/6922" class="">https://github.com/apple/swift/pull/6922</a>.</div><div class=""><br class=""></div><div class="">Rendered Proposal: <a href="https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7'" class="">https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7'</a></div></div></div></blockquote><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">-Chris</div><br class=""></div></div></blockquote></div><br class=""><div class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div><div class=""><br class=""></div><div class="">-Andy</div></body></html>