[swift-dev] "available externally" vs build time

[Erik Eckstein]

> On Jan 4, 2018, at 1:14 PM, Slava Pestov <spestov at apple.com> wrote:
> 
> 
> 
>> On Jan 4, 2018, at 1:08 PM, Erik Eckstein <eeckstein at apple.com <mailto:eeckstein at apple.com>> wrote:
>> 
>> 
>> 
>>> On Jan 2, 2018, at 1:08 PM, Slava Pestov via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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 at swift.org <mailto:swift-dev at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>>> 
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20180104/dd7c5ac5/attachment.html>