Deallocate dynamic allocas done for metadata/wtable packs. These
stackrestore calls are inserted on the dominance frontier and then stack
nesting is fixed up. That was achieved as follows:
Added a new IRGen pass PackMetadataMarkerInserter; it
- determines if there are any instructions which might allocate on-stack
pack metadata
- if there aren't, no changes are made
- if there are, alloc_pack_metadata just before instructions that could
allocate pack metadata on the stack and dealloc_pack_metadata on the
dominance frontier of those instructions
- fixup stack nesting
During IRGen, the allocations done for metadata/wtable packs are
recorded and IRGenSILFunction associates them with the instruction that
lowered. It must be the instruction after some alloc_pack_metadata
instruction. Then, when visiting the dealloc_pack_metadata instructions
corresponding to that alloc_pack_metadata, deallocate those packs.
When allocating, the shape is computed, and it (its constant value if
any) is needed when deallocating, so return the shape along with the
address. And when deallocating, accept the shape, which the client
received during allocation, rather than requiring that the caller
compute the fixed size.
When a metadata pack is heap allocated, the pointer's LSB is set.
But lldb is expecting a real pointer. So mask it off.
Companion PR has a test: https://github.com/apple/llvm-project/pull/6961
rdar://110195273
For now these are completely resilient blobs, which is wrong
because it prevents us from being able to model something like
(Int, repeat each T, String).
But one step at a time...
I'm not really convinced that the existing implementation here is
correct in general; it might work for the type checker's use cases,
but I don't think we can rely on not seeing opened element archetypes
from other expansions in the type we're processing here. But we can
at least tread water while offering a more convenient API.
This simplifies the representation and allows clients to handle fewer
cases. It also removes an ambiguity in the representation which could
lead us to have two canonical types for the same type.
This is definitely not working yet, but I'm not making progress on
it quickly enough to unblock what we need to unblock; it'll have to
be fixed in parallel.
Previously, only the element archetypes that corresponded to the
relevant pack generic parameters were bound, and the wtables that were
bound for them were based on looking up what they conform to. Here, the
requirements of the generic signature are used to find which archetypes
must be bound to metadata and which conformances must be bound to
wtables.
Previously wtable packs were never forwarded because pack types
consisting of a single element which was itself a pack archetype were
never canonicalized into that.
In the forwarding scenario, gepped and loaded from wtable when lowering
open_pack_element.
Call out to the infrastructure for emitting witness table packs to emit
references to individual witness tables when binding opened archetypes
during open_pack_element.
The parameter name to emitPackExpansionElementMetadata matched the
preexisting local variable name. Change it to something meaningful to
callers. Use a separate commit to make the original extraction more
obviously just an extraction.
The function emits the metadata for the element of a pack expansion at a
specified index. It was previously defined inline in the loop--defined
in emitPackExpansionType--which populates a new metadata array with
elements derived from a preexisting array. It will be used to emit a
single element in the case that only one is needed.
