> On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev > <swift-dev@swift.org> wrote: > > Folks working on the SIL optimizer, particularly those interested in faster > builds: > > If I understand the SIL optimizer correctly, it seems that when the current > program references an external symbol declared as @_inlinable, that > SILModule::linkFunction eagerly deserializes the @_inlinable body and splat > it into the current module. That SIL function exists in the current module, > gets optimized, inlined, etc along with existing functions, then gets dropped > on the floor at IRGen time if it still exists.
I’ve noticed this too, but haven’t had time to look at it yet. > If this is true, this seems like an incredibly wasteful approach, > particularly given how many @_inlinable functions exist in the standard > library, and particularly for programs that have lots of small files. Try > this: I agree! > 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? This seems like a clear win. > 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. What if we deserialized function bodies lazily instead of deserializing the transitive closure of all serialized functions referenced from a function? Slava > > I haven’t done any measurements, but this seems like it could be a big > speedup, particularly for programs containing a bunch of relatively small > files and not using WMO. > > -Chris > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
