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

[Slava Pestov]

Oh right. @_specialize modifies the original entry point to do runtime dispatch among the possible specializations. So the overhead comes from the unnecessary checks. I guess ideally we would have two versions of @_specialize, one adds the runtime dispatch whereas the other one just publishes static specializations which can be deserialized and used as needed.

Since @_specialize is not an officially supported attribute though, I would suggest punting this discussion until someone decides to push through an evolution proposal for it. For all intents and purposes, @inlinable is a superset of @_specialized because it defers the specialization decisions to the client.

Slava

> On Oct 4, 2017, at 11:47 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
> 
> See the thread <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038571.html> from july over generic trig functions, where @_specialize() + @_inlineable had a small but consistent performance penalty relative to @_inlineable alone.
> 
> On Thu, Oct 5, 2017 at 1:32 AM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
> 
> 
>> On Oct 4, 2017, at 11:04 PM, Taylor Swift <kelvin13ma at gmail.com <mailto: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/20171005/60f33f07/attachment.html>