> On Jan 2, 2018, at 1:08 PM, Slava Pestov via swift-dev <swift-dev@swift.org> > wrote: > > > >> 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.
+1 It should be a trivial change and I’m wondering why we haven’t done this yet. I filed https://bugs.swift.org/browse/SR-6697 > >> 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? 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. >> Would it make sense to put deserialized function bodies into a separate SIL >> module We serialize early in the pipeline, i.e. serialized functions are not (fully) optimized. 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. 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. > > 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 _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
