[PATCH] D99048: [RFC][DebugInfo] Do not use the DBG_VALUE to calculate debug info of spill location

[Jeremy Morse via Phabricator via llvm-commits]

jmorse added a comment.

Thanks for the reproducer; I think I see the same as you, when LiveDebugValues runs:

  MOV32mr $rsp, 1, $noreg, 8, $noreg, $r9d :: (store 4 into %stack.3)
  [...]
  DBG_VALUE $rsp, 0, !"f", !DIExpression(DW_OP_plus_uconst, 8), debug-location !983; test1.cpp:0 line no:16 indirect

Followed by, later on:

  MOVSDmr $rsp, 1, $noreg, 8, $noreg, killed renamable $xmm0 :: (store 8 into %stack.3)

Where the MOVSDmr writes to the stack slot the DBG_VALUE refers to. Unfortunately, there currently isn't a way for LiveDebugValues to connect the DBG_VALUE to the write into %stack.3 at this time. Doing so would involve parsing quite complicated DIExpressions, mapping back to a stack offset, finding the corresponding frame index and then scanning the function for stores to that stack slot. Doing so would be fragile, and we're trying to get away from heavily interpreting DIExpressions. Ultimately, this is because a lot of information is lost when regalloc / LiveDebugVariables runs.

This isn't fixed in the other LiveDebugValues implementation due to the complexity; instead it's fixed in a series of patches that haven't landed yet, by trying to avoid dropping information during regalloc. Those patches *might* be ready for the next release of LLVM, definitely behind an opt-in flag though.



================
Comment at: llvm/lib/CodeGen/LiveDebugValues/VarLocBasedImpl.cpp:1313
       })) {
-    // Use normal VarLoc constructor for registers and immediates.
-    VarLoc VL(MI, LS);
-    // End all previous ranges of VL.Var.
-    OpenRanges.erase(VL);
+    if (!MI.isIndirectDebugValue()) {
+      // Use normal VarLoc constructor for registers and immediates.
----------------
dongAxis1944 wrote:
> dongAxis1944 wrote:
> > @jmorse If the MI is indirect DBG_VALUE, does it mean the positions of variable is in the stack?
> I just want to skip the DBG_VALUE related to the spill location. Because I find the function "VarLocBasedLDV::transferSpillOrRestoreInst" can handle spill location well
(The "isIndirect" flag is quite a pain, and hopefully it'll be eliminated when everything becomes DBG_VALUE_LIST instructions in the coming few months,)

Right now isIndirect does indeed mean the variable is on the stack -- as opposed to the variable being the stack _pointer_. Alas, we can't just ignore these DBG_VALUEs as we'll drop numerous variable locations. Pre-regalloc DBG_VALUEs of a vreg translate into indirect DBG_VALUEs when that vreg is placed on the stack at the position of the DBG_VALUE.

This is different to following a variable that's in a register onto and off-of the stack via transferSpillOrRestoreInst; it's a variable that is assigned a value that is on the stack at that time.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99048/new/

https://reviews.llvm.org/D99048