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

[Roman Levenstein]

> On Oct 5, 2017, at 12:01 AM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

The support for publishing static specializations is envisioned in the current implementation of @_specialize already, though it is not well tested yet.

If you use the "exported: true" parameter with @_specialize, the body of the produced specialization would not be SIL serialized, but it will emitted into the object file of the defining module and the specialized function will be made available as a public symbol in the object file, so that the clients can link against it and invoke it directly. Since clients can refer to this symbol now, it cannot be removed in the future versions of the library as it would break all such clients linked against it.

@_specialize(exported: true, where K == Int, V == Int)
func foo<K, V>(dict: Dictionary<K, V>) {
}

We could also allow for making those exported specializations @inlinable if required by the user.

-Roman

> 
> 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 <mailto: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
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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