<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">On Dec 1, 2016, at 11:48 AM, Andrew Trick &lt;<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>&gt; wrote:<br class=""><br class="">Responding on swift-dev to what turned into an interesting discussion…<br class=""><br class=""><blockquote type="cite" class="">On Dec 1, 2016, at 11:19 AM, Joe Groff &lt;<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>&gt; wrote:<br class=""><br class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="">On Dec 1, 2016, at 11:18 AM, Joe Groff &lt;jgroff@apple.com&gt; wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class="">On Dec 1, 2016, at 11:16 AM, Andrew Trick &lt;atrick@apple.com&gt; wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Dec 1, 2016, at 10:34 AM, Jordan Rose &lt;jordan_rose@apple.com&gt; wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class="">On Nov 30, 2016, at 18:16, Joe Groff &lt;jgroff@apple.com&gt; wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class="">On Nov 30, 2016, at 6:10 PM, Andrew Trick &lt;atrick@apple.com&gt; wrote:<br class=""><br class="">We definitely want an inline-at-Onone, but I assumed we were treating "@inline(__always)" as a normal heuristic because:<br class="">- @transparent already does inline-at-Onone.<br class="">- @inline(__always) without @transparent negatively affects the debug experience.<br class="">- @inline(__always) isn't useful if no optimizations are run after inlining.<br class=""><br class="">That said, if the common expectation is for @inline(__always) to kick in independent of optimization, then we should honor that.<br class=""><br class="">It's easy for me to add an inlining pass to runSILPassesForOnone. I'm just not sure that will have the effect people are looking for. It's unlikely to help&nbsp;performance since nothing is going to run after the inlining (no capture promotion or alloc box-to-stack). The only optimization we currently run at Onone&nbsp;after diagnostics is prespecialization.<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><br class="">Actually, the inliner specializes as it goes, so inlining after mandatory SIL passes would still be quite useful.<br class=""><br class="">My concern is really that the user may expect inline(__always) to be as effective a performance tool as @transparent, while preserving debug line locations.<br class="">If it runs late, it doesn’t expose capture promotion, box-to-stack, guaranteed ARC optimization, etc.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">If someone is using inline(__always) for -Onone performance reasons, I think they really need to use @transparent.<br class=""><br class="">An alternative is to have @inline(__always) be another way to spell @transparent. People would need to implicitly know that this would affect diagnostics&nbsp;of the inlined method.<br class=""><br class="">Any thoughts?<br class=""></blockquote><br class="">`@transparent` doesn't just mean "inline-at-Onone", it also allows diagnostic passes to constant-fold through the implementation and actively eliminates&nbsp;debug information. It was never intended to be used for performance, but only for the limited set of things that need it. I imagine that the specialization you&nbsp;get by inlining some things is pretty important by itself. I suspect closure inlining would also be helpful for a lot of low-level "with*" combinators; doesn't&nbsp;transparent inlining do that, and could inline-always-inlining do the same?<br class=""></blockquote><br class="">For reference:&nbsp;<a href="https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst" class="">https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst</a><br class=""></blockquote><br class="">The only remaining question: is it ok for a non-transparent function to be inlined prior to running some dataflow diagnostics?<br class=""></blockquote><br class="">Doing so changes the set of programs that are accepted, since it may expose more code to diagnostic passes. We don't want diagnostics to depend on&nbsp;optimizations.<br class=""></blockquote><br class="">Perhaps we could avoid this by changing the diagnostic passes to intentionally ignore instructions with inlined source locations, though that seems brittle.<br class=""><br class="">-Joe<br class=""></blockquote><br class="">Well, inline(__always) would be mandatory, not an optimization. But I think your point is that the user does not expect that attribute to affect program legality. Having&nbsp;data-flow diagnostics “ignore” certain instructions sounds horrible. Is there an obvious problem, or is this hypothetical? i.e. is there some diagnostic that is currently&nbsp;enforced at the function boundary but would be considered legal code after inlining?<br class=""></blockquote><br class=""><div class="">An example of something that depends on dataflow diagnostics would be something that's constant-foldable causing static overflow diagnostics:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">func double(_ x: UInt8) -&gt; UInt8 {</div><div class="">&nbsp; return x + x</div><div class="">}</div><div class=""><br class=""></div><div class="">_ = double(128)</div></blockquote><div class=""><br class=""></div><div class="">Making `double` transparent causes the compiler to statically reject the call:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><b class="">/Users/jgroff/bar.swift:6:5: </b></span><span style="font-variant-ligatures: no-common-ligatures; color: #c33720" class=""><b class="">error: </b></span><span style="font-variant-ligatures: no-common-ligatures" class=""><b class="">arithmetic operation '128 + 128' (on unsigned 8-bit integer type) results in an overflow</b></span></div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">_ = double(128)</span></div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(52, 188, 38); background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><b class="">&nbsp; &nbsp; ^</b></span></div></div></blockquote><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><b class=""><br class=""></b></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class="">-Joe</span></div></body></html>