This is a fix for PR39896 [0], where SDNodes that have been optimised out do not lead to "DBG_VALUE undef" instructions being created. Such undef instructions are necessary to terminate earlier variable ranges, otherwise variable values leak past the point where they're valid.
The "invalidated" flag of SDDbgValue is currently being abused to mean two things:
- The corresponding SDNode is now invalid
- This SDDbgValue should not be emitted
Of which there are several legitimate combinations of meaning:
- The SDNode has been invalidated and we should emit "DBG_VALUE undef"
- The SDNode has been invalidated but the debug data was salvaged, don't emit anything for this SDDbgValue
- This SDDbgValue has been emitted
I've added an "Emitted" field to distinguish when the SDNode is invalid and when we just don't want to emit it. A SDDbgValue can be re-emitted too, because it seems to happen twice for some dbg.addrs, specifically DebugInfo/X86/dbg-addr-dse.ll gets DBG_VALUEs at the start of the function and in the middle.
As well as the regression test added, I've edited three tests, explained here:
LLVM :: DebugInfo/X86/pieces-3.ll The tail of this function is some completely superfluous computations that have dbg.values attached, and gets optimised out. Previously this was ignored by SelectionDAG, but now we emit a DBG_VALUE undef it reduces the range of the variables. Seeing how the tail is needless, and isn't generated by clang for the given source code, I've just deleted it. Otherwise emitting undef is correct, because the designated value was optimised out. LLVM :: DebugInfo/NVPTX/debug-info.ll The full debug info section is part of the test here, and has some kind of fractional change. I've just updated the lines to the latest version. LLVM :: DebugInfo/X86/dbg-value-inlined-parameter.ll According to a FIXME, some parameter was accidentally dropped on Linux. It now doesn't, so I've normalised the test here.
Why is this necessary?