> On Jan 4, 2018, at 2:11 PM, Erik Eckstein via swift-dev <swift-dev@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
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
