The pointsToEnd flag is only meaningful when combined with an AST node, and
moving it into the AST pointer frees up a bit in the flags bitfield for later
use.
whichever case it happens to be in.
This is a basic fix so that parallel walks on tuples and function
types in the substituted type will work . Separately, though, I
do not think the places that use this really need to be passed an
orig type; this is used for computing type properties, and I am
not aware of any reason we should need an orig type to compute
type properties. Additionally, the orig types computed by this
function are not really correct because of the substitution being
done in some cases, so it'd be very nice to rip this all out.
I'm not good to look into that right now, though.
Use BasicBlockBitfield to record per-block liveness state. This has
been the intention since BasicBlockBitfield was first introduced.
Remove the per-field bitfield from PrunedLiveBlocks. This
(re)specializes the data structure for scalar liveness and drastically
simplifies the implementation.
This utility is fundamental to all ownership utilities. It will be on
the critical path in many areas of the compiler, including at
-Onone. It needs to be minimal and as easy as possible for compiler
engineers to understand, investigate, and debug.
This is in preparation for fixing bugs related to multi-def liveness
as used by the move checker.
Allows migration of existing data-structures to bitfields by
separating the state that contains the bitfield into a separate
stack-allocated container.
The verify-di-hole SILVerifier pass is very useful in catching incorrectly set
SILDebugScopes, but it can be very tedious to track down the root cause of a
verification failure. This patch replicates much of its functionality inside an
assertion in SILBuilder, which will result in a backtrace pointing directly to
where the offending scope is being set.
and not also drop a subst parameter.
This turned out to be more convenient for certain clients (e.g. SILGenPoly)
than requiring the full subst param list to be passed in. These clients
want to process the subst param list separately, and dropping self early
can be convenient for that. The only fundamental reason we need this
flag is for working with the orig type, so just use it for that; clients
that need to use this feature can reasonably be expected to cooperate.
This is necessary because the use patterns in SILGenPoly require
walking two orig+subst sequences in parallel, which poses problems
for a callback-centric design like the one I addded before. An
inversion of control is necessary; this is basically a manual
coroutine. But frankly it's a nicer interface than the callback
design, too; I switched the implementation of forEachFunctionParam
to use the generator just to avoid code duplication, but I might
try to remove it and switch all the clients over to the generator.
The main problems with the callback design are that (1) I wasn't
sure which values clients would want, and the result is that there
are a *lot* of parameters and (2) (relatedly) the types of those
parameters have to be written out explicitly, and some of them
are quite large. The generator code is just much nicer. Maybe
I can still give the generator a little unparameterized callback
to keep lexical loops simple.
I'll need to do this same thing for tuples. One at a time.
This still does not have the complete behavior that we want since we are not yet
inserting the debug_value undef to invalidate after performing moves.
NOTE: In printed SIL, I decided to make the flag implicit if we have a
noncopyable type. This is just to reduce the bloat in SIL. If one needs this
property for a copyable type though, it is mandatory.
This is in preparation for wiring up debug info support for noncopyable
values. Originally this flag name made sense since it was set when we performed
consume operator checking. Now I am going to use it for noncopyable types as
well. I think the new name uses_moveable_value_debuginfo actually describes what
the flag is supposed to do, tell IRGen that the value may be moved since it
needs to use moveable value debug info emission.
Moves from limited use values are redundant. When a move separates a
non-escaping lifetime from an escaping lifetime, it is still redundant
if the original lifetime couldn't be optimized because it's already as
small as possible.
