[swift-evolution] Pitch: Cross-module inlining and specialization
spestov at apple.com
Thu Oct 5 01:32:15 CDT 2017
> 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution