In the prior revision, this file combined two approaches:
- the old approach of doing some fun things with arrays and hoping
that any important public and internal generic symbols will happen
to be specialized
- the new approach of explicitly specializing a generic symbol by
annotating a dummy "proxy" function with the actual generic mangled
name, then calling that proxy with an argument of the type to be
specialized.
Unfortunately, the symbols exposed by SwiftOnoneSupport have become
ABI. Therefore, the old approach can break over time because changes
to the compiler and standard library will affect which symbols happen
to be specialized. It can be extremely difficult to debug why those
symbols have gone missing.
The new approach will work to ensure ABI stability, but the
implementation was incomplete and the style of implementation would
not work in many cases. It was still relying on the old approach to
cover the generic symbols that weren't explicitly specialized. Also,
it wasn't clear to anyone reading the source what specializations of
those generic symbols are intended and required by the ABI.
This commit completely removes the old approach to prespecialization.
All generic symbols required by the ABI are now explicitly listed.
There are now several different proxy functions declared as methods
within the generic type that they represent. The parameter types of
each proxy function now match the parameter types of the generic
function. This guarantees that the compiler can correctly apply the
proxy function's subsitution map to the generic function's generic
signature. For example, it now handles subtitution of dependent types
(like Range<T>), substitutions that are not in the first parameter
position, and subsitition that occur in multiple parameters.
The proxy functions are now directly invoked with the concrete
argument type needed for specialization. There's no other incidental
code.
It is now possible to read this source and understand which standard
library functions need to be prespecialized on which types.
It's very unlikely that those functions are really referenced by Onone executables, but we want to be ABI compatible.
Also, there is no guarantee that this version of SwiftOnoneSupport will always trigger all symbol to be pre-specialized.
If the optimizer changes, we might need to add other explicit pre-specializations of internal stdlib symbols.
rdar://problem/48924409
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
In response to [SR-3334], which pointed out a large cost to iteration over
ReversedRandomAccessCollections at optimization level -Onone. By adding
iteration through a.reversed() in the _Prespecialize struct, we can get to
about the same performance as forward iteration.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 4%-5%.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 5%.
