> On Oct 4, 2017, at 11:04 PM, Taylor Swift <kelvin1...@gmail.com> wrote:
>
>
>
> On Oct 5, 2017, at 12:52 AM, Slava Pestov <spes...@apple.com
> <mailto:spes...@apple.com>> wrote:
>
>>
>>
>>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
