<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 12:11 PM, Andrew Trick &lt;<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>&gt; wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Dec 1, 2016, at 11:55 AM, Joe Groff &lt;<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>&gt; wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Dec 1, 2016, at 11:48 AM, Andrew Trick &lt;atrick@apple.com&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;jgroff@apple.com&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&nbsp;Onone 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&nbsp;diagnostics 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&nbsp;you 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;&nbsp;doesn't transparent inlining do that, and could inline-always-inlining do the same?<br class=""></blockquote><br class="">For reference:&nbsp;https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst<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.&nbsp;Having 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&nbsp;currently enforced at the function boundary but would be considered legal code after inlining?<br class=""></blockquote><br class="">An example of something that depends on dataflow diagnostics would be something that's constant-foldable causing static overflow diagnostics:<br class=""><br class="">func double(_ x: UInt8) -&gt; UInt8 {<br class="">&nbsp; return x + x<br class="">}<br class=""><br class="">_ = double(128)<br class=""><br class="">Making `double` transparent causes the compiler to statically reject the call:<br class=""><br class="">/Users/jgroff/bar.swift:6:5:&nbsp;error:&nbsp;arithmetic operation '128 + 128' (on unsigned 8-bit integer type) results in an overflow<br class="">_ = double(128)<br class="">&nbsp; &nbsp; ^<br class=""><br class="">-Joe<br class=""></blockquote><br class="">Right. In fact, constant propagation appears to be the only diagnostic that needs to run after mandatory inlining (I was misremembering SILDiagnostic pipeline):<br class=""></blockquote><br class=""><div class="">Unreachable code analysis is also affected. For instance:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">import Swift</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">func die() {</div></div><div class=""><div class="">&nbsp; Builtin.unreachable()</div></div><div class=""><div class="">}</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">func foo() -&gt; Int {</div></div><div class=""><div class="">&nbsp; die()</div></div><div class=""><div class="">&nbsp; // should get an error about missing return</div></div><div class=""><div class="">}</div></div></blockquote><div class=""><br class=""></div><div class="">If 'die()' is made transparent, then the "missing return" in foo() will be unexpectedly suppressed.</div><div class=""><br class=""></div><div class="">-Joe</div></body></html>