Simplify calls to getAddrOfLLVMVariableOrGOTEquivalent() and
getAddrOfLLVMVariable() by moving the computation of the alignment and
default type into LinkEntity.
Co-authored-by: Joe Groff <jgroff@apple.com>
A few utility methods would bypass computing the TypeInfo for a tuple,
but they were only used in assertions or used in places where I can't
imagine tuples coming up often enough for it to matter.
Rather than rely on the metadata initialization function to compute and
fill in the superclass, use the mangled superclass name to construct the
superclass metadata.
The superclass descriptor reference in class context descriptors is only used
for metadata bound computations when the superclass is resilient. Only
include the superclass descriptor reference when the class has a resilient
superclass, using a trailing record. It’s a tiny space savings for
classes that don’t have resilient superclasses.
Encode default associated type witnesses using a sentinel prefix byte
(0xFF) in the mangled name rather than as a second low bit on the
reference. Align all of the mangled names used for type references to
2 bytes (so we get that low bit regardless) and separate the symbol
names for default associated type witnesses vs. other kinds of
metadata or reflection metadata.
Indicate whether a particular associated type witness is a default (whose
mangled name is relative to the protocol) vs. being supplied as part of the
conformance (whose mangled name is relative to the conforming type). The
use of pointer identity to distinguish these cases can fail due to the
coalescing of these linker symbols.
Rather than storing associated type metadata access functions in
witness tables, initially store a pointer to a mangled type name.
On first access, demangle that type name and replace the witness
table entry with the resulting type metadata.
This reduces the code size of protocol conformances, because we no
longer need to create associated type metadata access functions for
every associated type, and the mangled names are much smaller (and
sharable). The same code size improvements apply to defaulted
associated types for resilient protocols, although those are more
rare. Witness tables themselves are slightly smaller, because we
don’t need separate private entries in them to act as caches.
On the caller side, associated type metadata is always produced via
a call to swift_getAssociatedTypeWitness(), which handles the demangling
and caching behavior.
In all, this reduces the size of the standard library by ~70k. There
are additional code-size wins that are possible with follow-on work:
* We can stop emitting type metadata access functions for non-resilient
types that have constant metadata (like `Int`), because they’re only
currently used as associated type metadata access functions.
* We can stop emitting separate associated type reflection metadata,
because the reflection infrastructure can use these mangled names
directly.
If a class has a backward deployment layout:
- We still want to emit it using the FixedClassMetadataBuilder.
- We still want it to appear in the objc_classes section, and get an
OBJC_CLASS_$_ symbol if its @objc.
- However, we want to use the singleton metadata initialization pattern
in the metadata accessor.
- We want to emit metadata for all field types, and call the
swift_updateClassMetadata() function to initialize the class
metadata.
For now, this function just performs the idempotent initialization of
invoking a static method on the class, causing it to be realized with
the Objective-C runtime.
For a resilient protocol that has defaulted associated types, emit
default associated conformance witnesses that compute associated
conformances based on that default witness.
This completes the implementation of resilience protocols that
add new, defaulted associated types, rdar://problem/44167982.
For a resilient conformance, emit the associated conformance accessor
functions into the resilient witness table (keyed on the associated
conformance descriptor) rather than in the fixed part of the witness
table. This is another part of resilience for associated conformances,
and a step toward defaults for associated conformances.
Associated conformance descriptors are aliases that refer to associated
conformance requirements within a protocol descriptor’s list of
requirements. They will be used to provide protocol resilience against
the addition of new associated conformance requirements (which only makes
sense for newly-introduced, defaulted associated types).
When an associated type witness has a default, record that as part of
the protocol and emit a default associated type metadata accessor into the
default witness table. This allows a defaulted associated type to be
added to a protocol resiliently.
This is another part of rdar://problem/44167982, but it’s still very
limiting because the new associated type cannot have any conformances.
SILWitnessTable::Entry already contains a superset of what was supported
by SILDefaultWitnessTable::Entry, the latter of which only had “no entry”
and “method” states. Make SILDefaultWitnessTable::Entry an alias for
SILWitnessTable::Entry, and unify all of the parsing/printing/
(de)serialization logic.
Generic parameter references, which occur in generic requirement
metadata, were hardcoding associated type indices. Instead, use
relative references to associated type descriptors and perform the
index calculation at runtime.
Associated types can now be reordered resiliently (without relying on
sorting), which is the first main step toward rdar://problem/44167982.
Introduce an alias that refers one element prior to the start of a
protocol descriptor’s protocol requirements. This can be subtracted from
an associated type descriptor address to determine the offset of the
associated type accessor within a corresponding witness table. The code
generation for the latter is not yet implemented.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
Previously we would emit class metadata for classes with resilient
ancestry, and relocate it at runtime once the correct size was known.
However most of the fields were blank, so it makes more sense to
construct the metadata from scratch, and store the few bits that we
do need in a true-const pattern where we can use relative pointers.
They were, already, but remove the isConstant parameter to
getAddrOfTypeMetadataPattern(), and just assert that its true for
patterns in defineTypeMetadata() instead.
Also, metadata patterns are i8*, not i8**. In fact they don't contain any
absolute pointers at all.
Should be NFC other than the LLVM type change.
It's confusing to have the generic and concrete type metadata
builders share a common base class, when most of the base class
is not used for the generic case.
Similar to the non-resilient case, except we also emit a 'relocation
function'. The class descriptor now contains this relocation function
if the class has resilient ancestry, and the relocation function
calls the runtime's swift_relocateClassMetadata() entry point.
The metadata completion function calls swift_initClassMetadata() and
does layout, just like the non-resilient case.
Fixes <rdar://problem/40810002>.
Now that we don't need the superclass before calling
swift_relocateClassMetadata(), it seems simpler to set it
here instead of doing it in various places in IRGen.
Using the superclass metadata here no longer makes sense with two-phase
init, in case the superclass metadata depends on the class being
instantiated.
It would also be nice to rework the resilient class metadata 'pattern'
to be its own data structure that's true const, instead of just the
prefix of a real class metadata, but for now let's keep the existing
crappy design.
If a class has generic ancestry or resiliently-sized fields, but is
itself not generic and does not have resilient ancestry, we must
perform runtime metadata initialization, but we can initialize
the metadata in-place.
As with generic classes or classes with resilient ancestry, we
copy generic requirements and field offset vectors from the
superclass. We also calculate the layout of the class's direct
fields at runtime.
Unlike the fully resilient case, we don't copy vtable entries
from the superclass, or install the direct class's vtable
entries from the type context descriptor. Instead, we statically
emit the vtable as with fixed-size class metadata.
Both the in-place and resilient case call the same runtime
entry point to initialize class metadata; the new HasStaticVTable
flag in ClassLayoutFlags is used to select between the two
behaviors concerning the vtable.
- doesClassMetadataRequireRelocation() -- returns true if we must
allocate new metadata at runtime and fill it in, because the class
has multiple instantiations (generic case) or because the total size
of the metadata is not known at compile time (resilient ancestry).
- doesClassMetadataRequireInitialization() -- weaker condition than
the above. It's true if the metadata must be relocated, but it is
also true if the metadata has otherwise fixed size but must be
filled in dynamically. This occurs if the class has generic
ancestry but is itself not generic, or if the class has
resiliently-sized fields, or missing members.
For now, we don't actually care about the distinciton anywhere,
because we cannot do in-place initialization of class metadata yet.
