NewProjection is a re-architecting of Projection that supports all of
the same functionality as Projection but in 1/3 of the original size (in
the common case). It is able to accomplish this by removing the base
type out of NewProjection itself and into users such as
NewProjectionPath. Thus NewProjection is now strictly an index from some
parent type rather than being a parent type and an index.
NewProjectionPath also has all of the same functionality as
ProjectionPath, but due to NewProjection being smaller than Projection
is smaller than ProjectionPath.
Used together NewProjection/NewProjectionPath yields the same output as
Projection/ProjectionPath when evaluating the LSLocation dumping tests.
Additionally, NewProjection is more flexible than Projection and will
for free give us the ability to perform AA on index_addr/index_raw_addr
as well as be able to integrate casts into the projection paradigm.
rdar://22484381
This commit is related to the work of encoding mangled names more efficiently by
compressing them. This commit adds two new methods to the mangler that allows it
to identify requests to mangle strings that are already mangled. Right now the
mangler does not do anything with this information.
This API is needed in all of the places in the compiler where we compose mangled
names. For example, when the optimizer is cloning functions it adds a prefix to
an existing name.
I verified that this change is correct by adding a compress/decompress methods
that add a prefix to the mangled names with assertions to catch compression of
already compressed symbols or decompression of non-compressed named. I plan to
commit the verification code together with the compression implementation later
on.
This commit changes the Swift mangler from a utility that writes tokens into a
stream into a name-builder that has two phases: "building a name", and "ready".
This clear separation is needed for the implementation of the compression layer.
Users of the mangler can continue to build the name using the mangleXXX methods,
but to access the results the users of the mangler need to call the finalize()
method. This method can write the result into a stream, like before, or return
an std::string.
Previously if one wanted to switch over just terminators, one would have
to use a ValueKind with a default case. This made it impossible for one
to use exhaustive switches on TermInsts and resulted in bugs (especially
when TryApply was added).
TermKind solves this problem by:
1. Having its cases defined by TERMINATOR cases in SILNodes.def.
2. Providing easy ways of mapping ValueKinds -> TermKinds. This is done
by providing a case called TermKind::Invalid and a struct
ValueKindAsTermKind which maps non-terminator ValueKinds to
TermKind::Invalid and real terminator ValueKinds to their respective
TermKind. Thus given a SILInstruction *, to switch over terminators, one
just does:
switch (ValueKindAsTermKind(I->getKind())) {
case TermKind::Invalid:
...
case TermKind::Return:
...
}
3. Providing a convenience method on TermInst called getTermKind() that
returns ValueKindAsTermKind(getKind()).
With these exhaustive switches, hopefully we can avoid such bugs in the
future.
This was once used in lldb but no longer is. I'm cannot find any other
users, so I'm removing it as a small part of cleaning up and simplifying
the SIL linking process.
This just runs a transform range on getSuccessor()'s ArrayRef<SILSuccessor> so
one does not need to always call Successor.getBB() when iterating over successor
blocks. Instead the transform range does that call for you.
I also updated some loops to use this new SILBasicBlock method to make sure that
the code is tested out by tests that are already in tree. All these places
should be functionally the same albeit a bit cleaner.
To determine whether it is safe to duplicate the instruction by duplicating the
loop body. Will be used in loop versioning for array and loop unrolling.
Debug variable info may be attached to debug_value, debug_value_addr,
alloc_box, and alloc_stack instructions.
In order to write textual SIL -> SIL testcases that exercise the handling
of debug information by SIL passes, we need to make a couple of additions
to the textual SIL language. In memory, the debug information attached to
SIL instructions references information from the AST. If we want to create
debug info from parsing a textual .sil file, these bits need to be made
explicit.
Performance Notes: This is memory neutral for compilations from Swift
source code, because the variable name is still stored in the AST. For
compilations from textual source the variable name is stored in tail-
allocated memory following the SIL instruction that introduces the
variable.
<rdar://problem/22707128>
