Previously, the extra data pattern structs for struct and enums were not
packed.
On 32 bit, this resulted in an extra data pattern struct which was 4
bytes too large whenever there was an odd number of fields in the
struct. The result was writing past the end of the allocated struct.
That bug only caused occasional crashes because (1) for the most part
there was additional space beyond the end of the allocation intended for
the struct metadata in the bump allocator and (2) while half of the
trailing flags field would be overwritten, because those bits of the
trailing flags being nonzero did not have an observable effect since
those bits of the trailing flags field are not yet used.
Here, the structs are marked packed, resulting in the appropriate size
for the extra data pattern structs on 32 bit platforms.
rdar://problem/68997282
By default, emitTypeMetadataRef does a blocking request for complete
metadata, which is the right thing to do for most purposes in IRGen.
Unfortunately, it's actively dangerous in code that can be called
during metadata completion, like an associated conformance accessor,
because it can cause artificial dependency cycles that the runtime
isn't equipped to detect, much less solve.
This is a partial fix for rdar://69901318, which also exposes a bad
metadata access path that seems to be causing an artificial problem.
Previously, the trailing flags field of runtime instantiated generic
metadata for types which had prespecialization enabled were not zeroed.
Consequently, the field always contained garbage. Often, metadata was
instantiated on new (and so, zeroed) pages, so the garbage happened to
be zero as is appropriate. However, when the metadata was instantiated
on pages which had previously been dirtied, the garbage value would
sometimes indicate that the metadata was canonical statically
specialized. When that occurred, swift_checkMetadataState would
incorrectly return a metadata state of complete, despite the fact that
the metadata might not in fact be complete. As a result, the runtime
was trafficking in incomplete metadata as if it were complete, resulting
in various crashes that would arise from for example missing a witness
table or a value witness table.
Here the problem is corrected. The trailing flags field of structs and
enums that have the field is set to 0.
For structs, this is accomplished by modifying the extra data pattern to
exist not only when there is fixed type info for the type but also when
the type is being prespecialized. Specifically, the extra data for a
struct is, rather than an i32 array of field offsets, a struct
consisting of none, one, or both of the following: (1) the array of
field offsets, (2) the trailing flags.
Similarly, enums now have an extra data pattern which consists of none,
one, or both of the following: (1) the payload size, (2) the trailing
flags. Enum metadata extra data setting was previously achieved by
customizing the metadata allocation function; that customization is now
eliminated, being replaced with the shared runtime code for copying
extra data into place, a modest code size savings.
rdar://problem/61465515
Previously, -Xfrontend -prespecialize-generic-metadata had to be passed
in order for generic metadata to be prespecialized. Now it is
prespecialized unless -Xfrontend
-disable-generic-metadata-prespecialization is passed.
This is essentially a long-belated follow-up to Arnold's #12606.
The key observation here is that the enum-tag-single-payload witnesses
are strictly more powerful than the XI witnesses: you can simulate
the XI witnesses by using an extra case count that's <= the XI count.
Of course the result is less efficient than the XI witnesses, but
that's less important than overall code size, and we can work on
fast-paths for that.
The extra inhabitant count is stored in a 32-bit field (always present)
following the ValueWitnessFlags, which now occupy a fixed 32 bits.
This inflates non-XI VWTs on 32-bit targets by a word, but the net effect
on XI VWTs is to shrink them by two words, which is likely to be the
more important change. Also, being able to access the XI count directly
should be a nice win.
Introduce a new runtime entry point, swift_getAssociatedConformanceWitness(),
which extracts an associated conformance witness from a witness table.
Teach IRGen to use this entry point rather than loading the witness
from the witness table and calling it directly.
There’s no advantage to doing this now, but it is staging for changing the
representation of associated conformances in witness tables.
Runtime functions need to use the Swift calling convention for any function
returning MetadataResponse, so that we get the two values returned in separate
registers.
Fixes rdar://problem/45042971 and rdar://problem/45851050.
Have clients pass the requirement base descriptor to
swift_getAssociatedTypeWitness(), so that the witness index is just one
subtraction away, avoiding several dependent loads (witness table ->
conformance descriptor -> protocol descriptor -> requirement offset)
in the hot path.
When an associated type defined in a given protocol has the same name as
an associated type in an inherited protocol, it is always equivalent to
the "overridden" associated type. Don't emit a new entry in the
witness table for the overriding associated type.
Saves ~68k of binary size in the standard library.
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.
This saves us some expensive cross-referencing and caching in the runtime, and lets us reclaim the `isReflectable` bit from the context descriptor flags (since a null field descriptor is a suitable and more accurate indicator of whether a type is reflectable).
Reimplement protocol descriptors for Swift protocols as a kind of
context descriptor, dropping the Objective-C protocol compatibility
layout. The new protocol descriptors have several advantages over the
current implementation:
* They drop all of the unused fields required for layout-compatibility
with Objective-C protocols.
* They encode the full requirement signature of the protocol. This
maintains more information about the protocol itself, including
(e.g.) correctly encoding superclass requirements.
* They fit within the general scheme of context descriptors, rather than
being their own thing, which allows us to share more code with
nominal type descriptors.
* They only use relative pointers, so they’re smaller and can be placed
in read-only memory
Implements rdar://problem/38815359.
It hass been a longstanding principle in LLVM that the presence of
debug info shall not affect code generation. This patch brings the
Swift frontend closer to this ideal:
- unconditionally emit shadow copies
- unconditionally bind type metadata
The extra allocas, bitcasts, geps, and stores being emitted get
optimized away when compiling at anything but -Onone. There are few
use-cases for compiling at -Onone without -g, so this shouldn't affect
performance for any real-world use-cases.
And update the existential container's initializeWithTake implementation
in the runtime. After only allowing bitwise takable values in the
inline buffer we can use memcpy to move existential container values.
rdar://31414907
SR-343
This adds the dllstorage annotations on the tests. This first pass gets
most of the IRGen tests passing on Windows (though has dependencies on
other changes). However, this allows for the changes to be merged more
easily as we cannot regress other platforms here.
Ensure that we use the correct python to run the python based tools.
This also allows these tools to run on Windows which will not
necessarily associate the python script with an interpreter (python).
Most of the work of this patch is just propagating metadata states
throughout the system, especially local-type-data caching and
metadata-path resolution. It took a few design revisions to get both
DynamicMetadataRequest and MetadataResponse to a shape that felt
right and seemed to make everything easier.
The design is laid out pretty clearly (I hope) in the comments on
DynamicMetadataRequest and MetadataResponse, so I'm not going to
belabor it again here. Instead, I'll list out the work that's still
outstanding:
- I'm sure there are places we're asking for complete metadata where
we could be asking for something weaker.
- I need to actually test the runtime behavior to verify that it's
breaking the cycles it's supposed to, instead of just not regressing
anything else.
- I need to add something to the runtime to actually force all the
generic arguments of a generic type to be complete before reporting
completion. I think we can get away with this for now because all
existing types construct themselves completely on the first request,
but there might be a race condition there if another asks for the
type argument, gets an abstract metadata, and constructs a type with
it without ever needing it to be completed.
- Non-generic resilient types need to be switched over to an IRGen
pattern that supports initialization suspension.
- We should probably space out the MetadataStates so that there's some
space between Abstract and Complete.
- The runtime just calmly sits there, never making progress and
permanently blocking any waiting threads, if you actually form an
unresolvable metadata dependency cycle. It is possible to set up such
a thing in a way that Sema can't diagnose, and we should detect it at
runtime. I've set up some infrastructure so that it should be
straightforward to diagnose this, but I haven't actually implemented
the diagnostic yet.
- It's not clear to me that swift_checkMetadataState is really cheap
enough that it doesn't make sense to use a cache for type-fulfilled
metadata in associated type access functions. Fortunately this is not
ABI-affecting, so we can evaluate it anytime.
- Type layout really seems like a lot of code now that we sometimes
need to call swift_checkMetadataState for generic arguments. Maybe
we can have the runtime do this by marking low bits or something, so
that a TypeLayoutRef is actually either (1) a TypeLayout, (2) a known
layout-complete metadata, or (3) a metadata of unknown state. We could
do that later with a flag, but we'll need to at least future-proof by
allowing the runtime functions to return a MetadataDependency.
This includes global generic and non-generic global access
functions, protocol associated type access functions,
swift_getGenericMetadata, and generic type completion functions.
The main part of this change is that the functions now need to take
a MetadataRequest and return a MetadataResponse, which is capable
of expressing that the request can fail. The state of the returned
metadata is reported as an second, independent return value; this
allows the caller to easily check the possibility of failure without
having to mask it out from the returned metadata pointer, as well
as allowing it to be easily ignored.
Also, change metadata access functions to use swiftcc to ensure that
this return value is indeed returned in two separate registers.
Also, change protocol associated conformance access functions to use
swiftcc. This isn't really related, but for some reason it snuck in.
Since it's clearly the right thing to do, and since I really didn't
want to retroactively tease that back out from all the rest of the
test changes, I've left it in.
Also, change generic metadata access functions to either pass all
the generic arguments directly or pass them all indirectly. I don't
know how we ended up with the hybrid approach. I needed to change all
the code-generation and calls here anyway in order to pass the request
parameter, and I figured I might as well change the ABI to something
sensible.
This regression wasn't caught by normal testing because the emission
pattern substantially changed anyway, breaking tests that were looking for
the field-offset vector, and because normal execution testing doesn't
actually use the field-offset vector and enum payload size fields.
Reflection, which does use these fields, was skating by for common types
because metadata is typically allocated out of freshly zeroed pages and
most such types have only one field.
Also, don't emit a completion function for value metadata with fixed layout.
We really shouldn't have to emit field-offset vectors for fixed-layout types;
the layout should just go in the type descriptor. But for now, this is what
we have to do.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
The allocation phase is guaranteed to succeed and just puts enough
of the structure together to make things work.
The completion phase does any component metadata lookups that are
necessary (for the superclass, fields, etc.) and performs layout;
it can fail and require restart.
Next up is to support this in the runtime; then we can start the
process of making metadata accessors actually allow incomplete
metadata to be fetched.
The layout changes to become relative-address based. For this to be
truly immutable (at least on Darwin), things like the RO data patterns
must be moved out of the pattern header. Additionally, compress the
pattern header so that we do not include metadata about patterns that
are not needed for the type.
Value metadata patterns just include the metadata kind and VWT.
The design here is meant to accomodate non-default instantiation
patterns should that become an interesting thing to support in the
future, e.g. for v-table specialization.
Change the "metadata base offset" variable into a "class metadata bounds"
variable that contains the base offset and the +/- bounds on the class.
Link this variable from the class descriptor when the class has a resilient
superclass; otherwise, store the +/- bounds there. Use this variable to
compute the immediate-members offset for various runtime queries. Teach the
runtime to fill it in lazily and remove the code to compute it from the
generated code for instantiation. Identify generic arguments with the start
of the immediate class metadata members / end of the {struct,enum} metadata
header and remove the generic-arguments offset from generic type descriptors.
This is yet another waypoint on the path towards the final
generic-metadata design. The immediate goal is to make the
pattern a private implementation detail and to give the runtime
more visibility into the allocation and caching of generic types.
All of the information contained by this field (list of property names)
is already encoded as part of the field reflection metadata and
is accessible via `swift_getFieldAt` runtime method.
This new format more efficiently represents existing information, while
more accurately encoding important information about nested generic
contexts with same-type and layout constraints that need to be evaluated
at runtime. It's also designed with an eye to forward- and
backward-compatible expansion for ABI stability with future Swift
versions.
