The current DebugValueManager, which is mostly used in RegStackify,
simply sinks DBG_VALUEs along when a def instruction sinks.
(RegStackify only does sinks; it doesn't do hoists.)
But this simple strategy can result in incorrect combinations of
variables' values which would have not been possible in the original
program. In this case, LLVM's policy is to make the value unavailable,
so they will be shown as 'optimized out', rather than showing inaccurate
debug info. Especially, when an instruction sinks, its original
DBG_VALUE should be set to undef. This is well illustrated in the
third example in
https://llvm.org/docs/SourceLevelDebugging.html#instruction-scheduling.
This CL rewrites DebugValueManager with this principle in mind. When
sinking an instruction, it sinks its eligible DBG_VALUEs with it, but
also leaves undef DBG_VALUEs in the original place to make those
variables' values undefined.
Also, unlike the current version, we sink only an eligible subset of
DBG_VALUEs with a def instruction. See comments in the code for
details.
In case of cloning, because the original def is still there, we don't
set its DBG_VALUEs to undef. But we clone only an eligible subset of
DBG_VALUEs here as well.
One consequence of this change is that now we do sinking and cloning of
the def instruction itself within the DebugValueManager's sink and
clone methods. This is necessary because the DebugValueManager needs
to know the original def's location before sinking and cloning in order
to scan other interfering DBG_VALUEs between the original def and the
insertion point. If we want to separate these two, we need to call
DebugValueManager's sink and clone methods before
sinking/cloning the def instruction, which I don't think is a good
design alternative either, because the user of this class needs to pay
extra attention when using it.
Because this change is fixing the existing inaccuracy of the current
debug info, this reduces the variable info coverage in debug info, but
not by a large margin. In Emscripten core benchmarks compiled with
-O1, the coverage goes from 56.6% down to 55.2%, which I doubt will be
a noticeable drop. The compilation time doesn't have any meaningful
difference either with this change.
IIRC SmallVectorImpl<MachineInstr *> is preferred over an explicit size for parameters, since any size would work.