[swift-evolution] Pitch: Cross-module inlining and specialization

[Chris Lattner]

> On Oct 4, 2017, at 9:24 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> - It increases binary size for a function that's rarely used, and which is often much larger as an outlined generic function than the simple operation that can be inlined into client code. Inlining makes the most sense when the inlined operation is smaller than a function call, so in many cases the net dylib + executable size would increase.
> 
> I can see this argument, but you’re basically saying that a sufficiently smart programmer can optimize code size based on (near) perfect knowledge of the symbol and all clients.  I don’t think this is realistic for a number of reasons.  In general, an API vendor has no way to know:
> 
> 1) how many clients it will have, potentially in multiple modules that get linked into a single app.
> 2) on which types a generic function will be used with.
> 3) what the code size tradeoffs ARE, e.g. if you have a large function that doesn’t use the archetype much, there is low bloat.
> 
> Furthermore, we have evidence from the C++ community that people are very eager to mark lots of things inlinable regardless of the cost of doing so.  Swift may end up being different, but programmers still have no general way to reason about code size given their declaration and without perfect knowledge of the clients.
> 
> The code of the approach I’m advocating is one *single* implementation gets generated in the module that defines the decl.  This can lead the N instantiations of exactly the same unspecialized code (consider the currying and other cases) in N different modules that end up in an app.  This seems like the right tradeoff.

Also, not all inlinable functions are generic.  There are perfectly rationale reasons to inline non-generic functions as well, and they don’t benefit from the specialization benefits you’re indicating.

Finally, even if a symbol is generic, it isn’t certain that the client will be able to specialize.  The calls may be from unspecialized code after all.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171004/fa54742b/attachment.html>