> On Jan 4, 2018, at 1:14 PM, Slava Pestov <spes...@apple.com> wrote: > > > >> On Jan 4, 2018, at 1:08 PM, Erik Eckstein <eeckst...@apple.com >> <mailto:eeckst...@apple.com>> wrote: >> >> >> >>> On Jan 2, 2018, at 1:08 PM, Slava Pestov via swift-dev <swift-dev@swift.org >>> <mailto:swift-dev@swift.org>> wrote: >>> >>> >>> >>>> On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev >>>> <swift-dev@swift.org <mailto: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 >> <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. > > However, imagine if f() calls g() which calls h() which calls i(). If all > four of f, g, h, and i are serialized, then we will deserialize them all as > soon as anything references f(). But the performance inliner might choose to > inline f(), and not g(), therefore the deserialization of h() and i() is > unnecessary. > > Or am I misunderstanding the issue here?
To make the inlining decision for g() into f() the optimizer looks at h() and i() as well. But the question is if the additional compile time this is worth the improved accuracy. We could definitely do something more intelligent and/or compile time favorable here. > >> >>>> 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 <mailto:swift-dev@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-dev >>>> <https://lists.swift.org/mailman/listinfo/swift-dev> >>> >>> _______________________________________________ >>> swift-dev mailing list >>> swift-dev@swift.org <mailto:swift-dev@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-dev >>> <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
