[llvm-dev] DBG_VALUE placement in post-RA scheduling
Jeremy Morse via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 3 05:18:10 PDT 2021
On Wed, Jun 2, 2021 at 10:14 PM Nagurne, James via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I can’t imagine that this is expected. The knowledge that the use of $0 in the new 1) is ‘variable_name’ is lost. Furthermore, we now have a strange liveness problem in that the DBG_VALUE is apparently killing $r0, which sounds logically incorrect.
Unfortunately this is expected, even though it's highly undesirable.
Because DBG_VALUE instructions specify both the program position where
a variable is assigned a location, and the register location too,
correctly placing DBG_VALUEs after scheduling becomes extremely
difficult. If we prioritise placing them near the position they were
before scheduling we would often get the register location wrong. If
we focused on the register location always being correct, we would
then often get the program position wrong, re-ordering assignments. I
believe the current solution gets position/register-location wrong
occasionally, but not especially often.
Shameless plug: my instruction-referencing rewrite of variable
locations  would make this easier, as the concern about register
locations is separated, and we would only need to think about where in
the program to place DBG_INSTR_REF instructions after scheduling. It's
back in the landing-patches  phase and might be production ready
for llvm 14, but possibly not for VLIW machines, it's been a long time
since I've gone near them.
> BUNDLE implicit $r0
> use $r0
> BUNDLE implicit $r0
> DBG_VALUE $r0, $noreg, !”variable_name”
> After the fixup step, both bundles are marked as kills of $r0, I believe as a consequence of the fact that the fixup step skips debug instructions at the top level, but not at the bundle level. This triggers the MachineVerifier to complain that the bundle containing the DBG_VALUE is using an undefined register because the prior bundle killed it.
This sounds fixable -- all register uses in DBG_VALUE / DBG_VALUE_LIST
instructions should have the "IsDebug" flag set on them, which should
allow the verifier to distinguish between "the code is broken" and
"the debug-info is faulty", the latter being non-fatal. I've no
familiarity with instruction bundles, but I'd guess the "IsDebug" flag
can be propagated to their uses, or otherwise interpreted when
checking their validity.
More information about the llvm-dev