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

[Chris Lattner]

> On Jan 4, 2018, at 2:11 PM, Erik Eckstein via swift-dev <swift-dev at swift.org> wrote:
> 
>>> 
>>> 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.
> 

Consider Slava’s example of "f() calls g() which calls h() which calls i()” where “f” is in the user module and g/h/i are in the standard library.

In most cases, when building the standard library, h and i will be inlined into g and should be serialized as just g with no calls in it.  If you have a summary for the size of g (and whatever other heuristics the inliner is using) you can consult that and avoid deserializing the function if it doesn’t make sense to inline g/h/i.

OTOH, if “h" was too big to inline into “g”, then you’d consult the summary for “g” and decide whether it makes sense to inline g into f.  At that point, you have a call to h, and consult the summary for h to see if it makes sense to inline it, etc.

In other words, this all composes.

-Chris

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