<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 Dec 1, 2016, at 11:55 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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 <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> 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 <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> 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 <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class="">On Dec 1, 2016, at 11:16 AM, Andrew Trick <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Dec 1, 2016, at 10:34 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class="">On Nov 30, 2016, at 18:16, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class="">On Nov 30, 2016, at 6:10 PM, Andrew Trick <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> 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 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 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 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 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 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 transparent inlining do that, and could inline-always-inlining do the same?<br class=""></blockquote><br class="">For reference: <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 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 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 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) -> UInt8 {</div><div class=""> 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=""> ^</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></div></div></blockquote></div><br class=""><div class=""><div class="">Right. In fact, constant propagation appears to be the only diagnostic that needs to run after mandatory inlining (I was misremembering SILDiagnostic pipeline):</div><div class=""><br class=""></div><div class=""> PM.addCapturePromotion();</div><div class=""> PM.addAllocBoxToStack();</div><div class=""> PM.addNoReturnFolding();</div><div class=""> PM.addDefiniteInitialization();</div><div class=""><br class=""></div><div class=""> PM.addMandatoryInlining();</div><div class=""> PM.addPredictableMemoryOptimizations();</div><div class=""> PM.addDiagnosticConstantPropagation();</div><div class=""> PM.addGuaranteedARCOpts();</div><div class=""><br class=""></div><div class="">I think PredicatableMemoryOptimization is a "required" optimization, not a diagnostic, and GuaranteedARCOpts is an "expected" optimization that doesn't need to be in the diagnostic pipeline at all.</div><div class=""><br class=""></div><div class="">I'm not sure it's actually bad for @inline(__always) to strengthen diagnostics, but it isn't the pure solution. So, in the interest of purity, I'll suggest this:</div><div class=""><br class=""></div><div class="">Diagnostic Pipeline:</div><div class=""><br class=""></div><div class=""> PM.addCapturePromotion();</div><div class=""> PM.addAllocBoxToStack();</div><div class=""> PM.addNoReturnFolding();</div><div class=""> PM.addDefiniteInitialization();</div><div class=""> PM.addMandatoryInlining();</div><div class=""> PM.addPredictableMemoryOptimizations();</div><div class=""> PM.addDiagnosticConstantPropagation();</div><div class=""><br class=""></div><div class="">Onone Pipeline:</div><div class=""><br class=""></div><div class=""> PM.addGuaranteedInlining();</div><div class=""> PM.addGuaranteedARCOpts();</div><div class=""><br class=""></div><div class="">Eventually we could add another round of PredictableMemoryOptimizations to the Onone pipeline if needed.</div></div><div class=""><br class=""></div><div class="">-Andy</div><div class=""><br class=""></div></body></html>