@_specialize attribute


(Andrew Trick) #1

I'd like to let people know that I'm introducing an @_specialize(...)
function attribute. See https://github.com/apple/swift/pull/1725.
Feedback is welcome. Just keep in mind that for now this is only an
internal attribute. It is not yet a language change and has no impact
on API. The intention of this work is to provide an underlying capability
that we can build on in several ways (see below).

<snip Generics.rst>
An internal @_specialize function attribute allows devlopers to force
full specialization by listing concrete type names corresonding to the
function's generic signature. A function's generic signature is a
concatenation of its generic context and the function's own generic
type parameters.::

  struct S<T> {
    var x: T
    @_specialize(Int, Float)
    mutating func exchangeSecond<U>(u: U, _ t: T) -> (U, T) {
      x = t
      return (u, x)
    }
  }

  // Substitutes: <T, U> with <Int, Float> producing:
  // S<Int>::exchangeSecond<Float>(u: Float, t: Int) -> (Float, Int)

@_specialize currently acts as a hint to the optimizer, which
generates type checks and code to dispatch to the specialized routine
without affecting the signature of the generic function. The
intention is to support efforts at evaluating the performance of
specialized code. The performance impact is not guaranteed and is
likely to change with the optimizer. This attribute should only be
used in conjunction with rigorous performance analysis. Eventually,
a similar attribute could be defined in the language, allowing it to be
exposed as part of a function's API. That would allow direct dispatch
to specialized code without type checks, even across modules.
</snip Generics.rst>

In the future, we can build on this work in several ways:
- cross module dispatch directly to specialized code
- dynamic dispatch directly to specialized code
- automated specialization based on broader hints
- partial specialization
- and so on…

Andy