<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 4, 2018, at 4:57 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@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=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 4, 2018, at 1:08 PM, Erik Eckstein <<a href="mailto:eeckstein@apple.com" class="">eeckstein@apple.com</a>> wrote:</div><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">1. It looks like the MandatoryInliner is the biggest culprit at -O0 here: it deserializes the referenced function (MandatoryInlining.cpp:384) and *then* checks to see if the callee is @_transparent. Would it make sense to change this to check for @_transparent first (which might require a SIL change?), and only deserialize if so?<br class=""></blockquote><br class="">This seems like a clear win.<br class=""></blockquote><br class="">+1<br class=""><br class="">It should be a trivial change and I’m wondering why we haven’t done this yet.<br class="">I filed <a href="https://bugs.swift.org/browse/SR-6697" class="">https://bugs.swift.org/browse/SR-6697</a><br class=""></div></div></blockquote><div class=""><br class=""></div>Thanks!</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">2. The performance inliner will have the same issue after this, and deserializing the bodies of all inlinable referenced functions is unavoidable for it. However, we don’t have to copy the SIL into the current module and burn compile time by subjecting it to all of the standard optimizations again. Would it make sense to put deserialized function bodies into a separate SIL module, and teach the (few) IPA/IPO optimizations about this fact? This should be very straight-forward to do for all of the optimizations I’m aware of.<br class=""></blockquote><br class="">What if we deserialized function bodies lazily instead of deserializing the transitive closure of all serialized functions referenced from a function?<br class=""></blockquote><br class="">Well, with our pass pipeline architecture I suspect it will not make a difference. We process functions bottom-up. For example, the performance inliner optimizes the callee first before trying to inline it (because it influences the inlining decision). So the performance inliner actually visits the whole call tree.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""> Would it make sense to put deserialized function bodies into a separate SIL module<br class=""></blockquote></blockquote><br class="">We serialize early in the pipeline, i.e. serialized functions are not (fully) optimized. </div></div></blockquote><div class=""><br class=""></div><div class="">Really? The serialized functions in the standard library aren’t optimized? That itself seems like a significant issue: you’re pushing optimized compile time cost onto every user’s source file that uses an unoptimized stdlib symbol.</div></div></div></div></blockquote><div><br class=""></div><div>First of all, serialized functions are optimized, but not with the full optimization pipeline. We serialize in the middle of the pass pipeline.</div><div>The reason for this is that we solve two problems with that:</div><div>1) We cannot serialize fragile functions which inlined resilient functions, because this would expose resilient code to the client. On the other hand we want to enable this kind of inlining for code generated in the module itself. In other words: we need a different optimization pipeline for code generation and serialization anyway.</div><div>2) The optimization pipeline is split into “high level” and “low level” regarding @_semantics functions. In the high-level part @_semantic functions are not inlined. If we serialize after such functions are inlined then we would de-serialize “low-level” sil into “high level” sil.</div><div><br class=""></div><div>I’m not worried about the compile time impact of early serialization. When we did that change we measured compile time and didn’t see a significant difference.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">And at least the performance inliner needs functions to be optimized to make good inlining decisions. So it makes sense to also optimize deserialized functions.<br class=""><br class="">That said, I’m sure there is still potential for improvements. For example, we could exclude deserialized generic functions from optimizations, because we only inline specialized functions.<br class=""></div></div></blockquote></div><br class=""><div class="">If the serialized functions are in fact optimized, you have a lot of ways to avoid deserializing in practice. There just aren’t that many IPO/IPA passes in the compiler, so you can build in summaries that they need into the serialized sil code. If they aren’t optimized, then there are bigger problems.</div></div></div></blockquote><div><br class=""></div><div>Inlining decisions also depend on the caller context, like function argument values, e.g. if a function argument is constant and that argument controls a condition in the callee, this is considered.</div><div>It’s possible to model this in a summary information, but it’s not trivial.</div><div>But, as I said, there are definitely many possibilities for improvements.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></body></html>