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

[Erik Eckstein]

> On Jan 4, 2018, at 4:57 PM, Chris Lattner <clattner at nondot.org> wrote:
> 
>> On Jan 4, 2018, at 1:08 PM, Erik Eckstein <eeckstein at apple.com <mailto:eeckstein at apple.com>> wrote:
>>>> 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>
> 
> Thanks!
> 
>>>> 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.
> 
> 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.

First of all, serialized functions are optimized, but not with the full optimization pipeline. We serialize in the middle of the pass pipeline.
The reason for this is that we solve two problems with that:
1) We cannot serialize fragile functions which inlined resilient functions, because this would expose resilient code to the client. On the other hand we want to enable this kind of inlining for code generated in the module itself. In other words: we need a different optimization pipeline for code generation and serialization anyway.
2) The optimization pipeline is split into “high level” and “low level” regarding @_semantics functions. In the high-level part @_semantic functions are not inlined. If we serialize after such functions are inlined then we would de-serialize “low-level” sil into “high level” sil.

I’m not worried about the compile time impact of early serialization. When we did that change we measured compile time and didn’t see a significant difference.

> 
>> 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.
> 
> 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.

Inlining decisions also depend on the caller context, like function argument values, e.g. if a function argument is constant and that argument controls a condition in the callee, this is considered.
It’s possible to model this in a summary information, but it’s not trivial.
But, as I said, there are definitely many possibilities for improvements.

> 
> -Chris
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20180104/7c503198/attachment.html>