When we generate code that asks for complete metadata for a fully concrete specific type that
doesn't have trivial metadata access, like `(Int, String)` or `[String: [Any]]`,
generate a cache variable that points to a mangled name, and use a common accessor function
that turns that cache variable into a pointer to the instantiated metadata. This saves a bunch
of code size, and should have minimal runtime impact, since the demangling of any string only
has to happen once.
This mostly just works, though it exposed a couple of issues:
- Mangling a type ref including objc protocols didn't cause the objc protocol record to get
instantiated. Fixed as part of this patch.
- The runtime type demangler doesn't correctly handle retroactive conformances. If there are
multiple retroactive conformances in a process at runtime, then even though the mangled string
refers to a specific conformance, the runtime still just picks one without listening to the
mangler. This is left to fix later, rdar://problem/53828345.
There is some more follow-up work that we can do to further improve the gains:
- We could improve the runtime-provided entry points, adding versions that don't require size
to be cached, and which can handle arbitrary metadata requests. This would allow for mangled
names to also be used for incomplete metadata accesses and improve code size of some generic
type accessors. However, we'd only be able to take advantage of the new entry points in
OSes that ship a new runtime.
- We could choose to always symbolic reference all type references, which would generally reduce
the size of mangled strings, as well as make runtime demangling more efficient, since it wouldn't
need to hit the runtime caches. This would however require that we be able to handle symbolic
references across files in the MetadataReader in order to avoid regressing remote mirror
functionality.
Correct the COMDAT handling for the type metadata emission. In
particular, declarations should not be emitted with COMDATs. The
pattern used in the compiler for the metadata emission is different than
the other structures. In particular, `getAddrOfTypeMetadata` emits the
declaration for the type metadata symbol. The definition for the type
metadata will be emitted via `defineTypeMetadata`. This change adjusts
the IRGen to remove the COMDAT on the declaration permitting the
definition from `defineTypeMetadata` being emitted strongly.
This exposes a bug in the LLVM MC layer which is a separate change that
will enable this to function properly.
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
dynamic-replacement runtime functions.
The recent change of how we do dynamic replacements added 2 new runtime
functions. This patch adds those functions to the Compatibility50 static
archive.
This will allow backward deployment to a swift 5.0 runtime.
Patch by Erik Eckstein with a modification to call the standard
libraries implementation (marked as weak) when it is available.
This ensures we can change the implementation in the future and are not
ABI locked.
rdar://problem/51601233
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
With the option -Xllvm -basic-dynamic-replacement the runtime functions are not called (so it works with an old swift library).
But calling the original of a replaced function is not supported in this case.
Instead of a thunk insert the dispatch into the original function.
If the original function should be executed the prolog just jumps to the "real" code in the function. Otherwise the replacement function is called.
There is one little complication here: when the replacement function calls the original function, the original function should not dispatch to the replacement again.
To pass this information, we use a flag in thread local storage.
The setting and reading of the flag is done in two new runtime functions.
rdar://problem/51043781
Fixes a build error:
/Users/local/swift/swift/lib/IRGen/GenDecl.cpp:1323:11: error: enumeration value 'XCOFF' not handled in switch [-Werror,-Wswitch]
All the other functions in this file group XCOFF and COFF together
so I guess this is a reasonable thing to do.
SR-10590 | rdar://problem/50968433 appears to be caused by an LLVM JIT bug where GOT-equivalent
globals get emitted with incorrect alignment. Not marking the GOT equivalent as unnamed_addr
(which prevents it from getting folded into the GOT, or other equivalent constants) appears
to work around the issue.
- In Sema, don't traverse nested declarations while deducing the opaque return type. This would
cause returns inside nested functions to clobber the return type of the outer function.
- In IRGen, walk the list of opaque return types we keep in the SourceFile already for type
reconstruction, instead of trying to visit them ad-hoc as part of walking the AST, since
IRGen doesn't normally walk the bodies of function decls directly.
Fixes rdar://problem/50459091
If -enable-anonymous-context-mangled-names is enabled, meaning that we assign names to
anonymous context descriptors for discovery by RemoteAST, then include opaque type descriptors
in the type metadata record table so that they can also be found at runtime by RemoteAST for
debugger support.
This is to support dynamic function replacement of functions with opaque
result type.
This approach requires that all state is thrown away (that could contain the
old returned type for an opaque type) between replacements.
rdar://48887938
