<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=""><div><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><br class=""></div>Thanks!</div><div><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><br class=""></div><div>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><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 class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></body></html>