This patch fixes PR40795 [0] by preventing constant-value variable locations from flowing into nearby basic blocks during location-list calculation, and propagates constant-value locations in LiveDebugValues to compensate for lost variable coverage.
As documented in comment 8 of the PR, the range that a constant-value DBG_VALUE defines a variable location over does not currently terminate at the end of the basic block the DBG_VALUE is in. Instead, its range is valid across all basic blocks (as finally laid out) until another DBG_VALUE for the variable is seen. This often covers many instructions where the variable didn't actually have a location, and even down code paths where the variable was never assigned the constant value. Fix this by keeping a set of InlinedEntity's that are not register locations, and terminating them all at the end of the block. I believe this problem was also true for stack spill locations.
In addition to this, LiveDebugValues does not propagate constant-value variable locations, so with only that change we would lose constant-value variable locations outside of the defining basic block -- on a clang3.4 build this leads to a 2% drop in overall scope-bytes-covered (45% -> 43%). To get around this, I've fixed LiveDebugValues to also propagate constant values in the same way it does other values. There are zero algorithmic changes, it just propagates from one place to another better now, although now VarLoc::operator== does more work to compare CImmediate / FPImmediate objects, as I don't believe their pointers are uniqued.
This probably leads to greater memory use due to increased DBG_VALUE propagation / replication, although I haven't made any memory-usage measurements. I've timed a clang-3.4 build using llvm/clang r354569 with and without this patch; the time differences were negligible and well within the margin of error.
Test changes: due to constant-value DBG_VALUE propagation COFF/pieces.ll now gets several new .Ltmp labels, which I've updated accordingly. New lines 63-66 reflect the fact that a new basic block has a variable location for loop_csr:o now where previously it was missing (the constant-value location is legitimate). Line 46 gets a new & spurious constant-value DBG_VALUE -- I believe this is due to the LiveDebugValues-ignores-backedges problem in PR38997 [1].
MIR/AArch64/implicit-def-dead-scope.mir: I'm not sure what to make of this test: it runs after LiveDebugValues, drops a constant DBG_VALUE somewhere, and expects it to be promoted to being function-wide. That no longer happens (checks updated) and I'd argue that given the control flow merges mean that it shouldn't. Possibly some input required here.
X86/fission-ranges.ll: LiveDebugValues now detects and records stack spills in the large loop produced by this input, hence many more location entries. It doesn't fully cover the whole function as none of the phi's have dbg.values in the input.
Added test: this is four diamond-pattern if conditionals in MIR, with different combinations of DBG_VALUE with register/constant locations on the branches of the condition. The CHECKs test how LiveDebugValues propagates them when control flow merges (it should when the locations agree; not when they do not), while the RANGES checks test that DbgEntityHistoryCalculator correctly terminates the range of variable locations at the end of basic blocks.
[0] https://bugs.llvm.org/show_bug.cgi?id=40795
[1] https://bugs.llvm.org/show_bug.cgi?id=38997#c6
Just as a small heads up, I uploaded D59941 and D59942 which aims to improve handling of fragments in DbgEntityHistoryCalculator and its users. If people think that the structure that those patches introduces is a good idea, then it should be possible to adapt this patch to that by using the LiveEntries map, which keeps indices for all currently open debug values. That way we can ensure that all open non-overlapping fragments are closed at the end of the basic block.