This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
swift::GeneratedModule encapsulates an llvm::Module, llvm::LLVMContext
pair that must live and die together. It has convenient accessors for
projecting the module and context components. The meat of this type is
the two conversion functions, which transfer ownership of either the
module component to the caller or the module and context to ORCJIT.
This is because ORC enforces an ownership contract that is distinct from
LLVM's rather wild ownership story for modules and their associated
contexts. See http://llvm.org/docs/ORCv2.html#how-to-use-threadsafemodule-and-threadsafecontext
This adds code that can be used to build recursive type layouts. And
code that generates value witness IR based on the recursive type
layouts.
Value witnesses generated based on type layouts will only refer to
archetypes when computing fields offsets for frozen generic types (vs
instantiated type medata).
rdar://51988441
Regardless of any flags, the stdlib will have its generic metadata
prespecialized.
Temporarily reintroduced the flag to enable the feature flag while
preserving the flag to disable it and changed the default back to off
for the moment.
SIL differentiability witnesses are a new top-level SIL construct mapping
an "original" SIL function and derivative configuration to derivative SIL
functions.
This patch adds `SILDifferentiabilityWitness` IRGen.
`SILDifferentiabilityWitness` has a fixed `{ i8*, i8* }` layout:
JVP and VJP derivative function pointers.
Resolves TF-1146.
Temporarily disable metadata prespecialization on platforms other than
MacOS, iOS, tvOS, watchOS, or Linux. At the moment, tests are failing
on Windows with linker errors such as
demangleToMetadata-558ea9.o : error LNK2001: unresolved external symbol $ss5Int64VN
demangleToMetadata-558ea9.o : error LNK2001: unresolved external symbol $sSSSHsWP
Once the issue leading to those linker errors has been resolved, the
feature will be enabled on Windows.
This was being done at an odd point in the frontend presumably because by that point the private discriminator had been fully computed. Instead, push the conditions for generating the prefix data down to debug info generation and stop mutating IRGenOptions::DebugFlag in the frontend.
ELF's lack of linker directives is worked around by a custom section
(`.swift1_autolink_entries`). This is metadata that is not intended to
be emitted into the linked binary. A previous change introduced the use
of a module (global) assembly gadget to discard the section. However,
this interacts poorly with ASAN which would instrument the section,
resulting in a strong reference. This reference would persist to a
discarded symbol. lld would object to this. Blacklist the symbol to
ensure that ASAN + autolinking can co-exist.
Compatibility with earlier swift runtimes would require modifying the
runtime compatibility libraries to adjust the behavior of
checkMetadataState by way of typeForMangledNode or even
typeForMangledName. For now, simply require that a version of swift
whose runtime knows about prespecialized metadata is being targeted.
autolink-extract is needed on ELF (and windows-cygnus). However, WASM
also has gone down this path and did not actually indicate that it
needed the autolink extract handling. Extract the handling check into a
variable which helps readability.
WASM currently is treated identically to the ELF paths. Collocate the
types to make it easier to ensure that all the paths are correctly
handling the emission. This adds the missed case for the module hash.
use getTypeByMangledName when abstract metadata state is requested
This can significantly reduce the code size of apps constructing deeply
nested types with conditional conformances.
Requires a new runtime.
rdar://57157619
The TAPI_SWIFT_ABI_VERSION macro was never updated in sync with
IRGen::swiftVersion, so just expose that value through
irgen::getSwiftABIVersion() and use it in TBDGen.
Fixes rdar://55643763
On targets which support COMDAT (PE/COFF, ELF), use that to relax the
constraints on the emission of `-force-autolink-symbol` so that it is
possible to use that with `-incremental`.
Mark the section .swift1_autolink_entries as SHF_EXCLUDE
so the section will get dropped by the linker after linking the final
binary.
This section is used to save the flags needed for auto link and there
is no reason it should stay in the final linked binary.Mark the
section .swift1_autolink_entries as SHF_EXCLUDE
so the section will get dropped by the linker after linking the final
binary.
This section is used to save the flags needed for auto link and there
is no reason it should stay in the final linked binary.
This solves issue SR-11247
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.
on behalf of the debugger. The debugger will read the LinkLibrary's
from all the modules it sees, and hand load all the required dependencies,
and since the symbol is weak it doesn't even tell us whether a
required dependency is missing. So it serves no purpose in this case.
<rdar://problem/51463642>
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
When backward deploying to an OS that may not have these entry points, weak-link them so that they
can be used conditionally in availability contexts that check for them.
rdar://problem/50731151
