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

[Chris Lattner]

> On Oct 4, 2017, at 9:40 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
> 
> 
> - It becomes an ABI compatibility liability that has to be preserved forever. 
> - 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.
> - It increases the uncertainty of the behavior client code sees. If an inlinable function must always be emitted in the client, then client code *always* gets the current definition. If an inlinable function calls into the dylib when the compiler chooses not to inline it, then you may get the current definition, or you may get an older definition from any published version of the dylib. Ideally these all behave the same if the function is inlinable, but quirks are going to be inevitable.
>  
> i’m just tryna follow along here && this is probably a dumb question, but is it possible for a generic function to be emitted as a set of specialized functions into the client, but not inlined everywhere? It can be the case where a large generic function gets slowed down by the large number of generic operations inside it but it doesn’t make sense for it to be inlined completely.

Yep, something like that would definitely be possible by a sufficiently smart compiler, it is compatible with both approaches.

-Chris

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