[PATCH] D56788: [DebugInfo][InstCombine] Prefer salvaging dbg.values over sinking them

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added inline comments.


================
Comment at: test/Transforms/InstCombine/debuginfo_add.ll:52
   ; CHECK-LABEL: for.body.lr.ph:
   ; CHECK-NEXT: %0 = load
+  ; CHECK-NEXT: br label %for.body
----------------
Shouldn't there still be som dbg.value for variable !25 after the load, indicating that the variable is in %0?

Have you checked what happens in the final output? It all might depend on which live range that is longest (%start or %0), but if this load is the last user of %start we only know how to get the value of the variable !25 from %0 after the load.

I'm also not sure how well LLVM handles these dbg.value intrinsics with DW_OP_deref. What defines the end of the debug range for those? The end of the BB? The next instruction that potentially can write to memory? When the pointer register is dead? The use of DW_OP_deref (in opt) has been quite rare so far (afaik). A direct mapping to the SSA value is a more well established concept (the dbg.value is valid for the range of the SSA value, or up until the next dbg.value that indicates that the variable is somewhere else). Perhaps also limited to the current BB (or is that only for DBG_VALUE and not dbg.value? or only after de-SSA?). But when we say that the variable is in memory (and not a unique stack slot for the variable), how do we know when this isn't valid any longer when calculating debug value ranges?


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

https://reviews.llvm.org/D56788