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

[Slava Pestov]

> On Oct 4, 2017, at 11:04 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
> 
> 
> 
> On Oct 5, 2017, at 12:52 AM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
> 
>> 
>> 
>>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 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.
>> 
>> This is already possible. The optimizer doesn’t have to inline an @_inlineable function at its call site; it can emit a call to a specialized version instead.
>> 
>> Slava
> 
> Is there a reason using @_specialize() and @_inlineable together is slower than using @_inlineable by itself?

By specialization, I mean the optimizer pass which takes a function body and substitutes generic parameters with statically-known types.

I’m not sure what your question means though. Adding a @_specialize attribute should never make anything slower. Rather it makes the optimizer eagerly emit specializations of a function in the defining module. You can think of @_specialize and @inlinable as mostly mutually exclusive; either you publish the complete function body for clients to optimize as they please, or you publish a fixed set of specializations.

You might prefer the latter for secrecy (serialized SIL is much closer to source code than machine code), but the the former enables more general optimizations.

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