[llvm-dev] [RFC] A value-tracking LiveDebugValues implementation

[Adrian Prantl via llvm-dev]

Jeremy,

thank you, that is quite a lot of work you put in there! Generally, speaking there is nothing wrong with replacing the current LiveDebugValues pass with a new implementation if the new implementation solves all the same problems, and is either simpler or faster, or more accurate. We just need to be sure to judge the "simpler" aspect only after all the ugly edge cases have been addressed.
The LLVM way of staging is is to land the new implementation in trunk, and when it's ready, make it the default, and then remove the old one. Unfortunately we have a track record of getting stuck after step 1, because it's always difficult to completely replace a matured implementation of anything.

I agree that tracking values instead of instructions is a very elegant way of dealing with the output of regalloc and spilling and that it would seem to have potential for longer live ranges for the individual debug values. I've skimmed your implementation and it looks nice and well-documented.

I had two thoughts while read while reading the proposal, but reflecting on it, I fell like these are not necessarily just problems with your proposal, but also problems with current implementation. I'm going to include them here because I already typed them out, but honestly they shouldn't affect our decision :-)

1. I was wondering about potential downsides of tracking values. I noticed that a surprising amount of developers like to modify variables in the debugger. DWARF allows this when you have memory or register locations, as opposed to (DW_OP) stack values. If we wanted to become better at this, tracking values sounds potentially dangerous, since we can't know if the same value in a different location has any correspondence with the variable any more. I suppose that even with the new algorithm we could insert a hypothetical DBG_DECLARE at the definition and a DBG_VALUE when the register is moved. I guess there is no theoretical limit to supporting this with the value tracking approach.

2. When tracking values, do we keep track of the original DBG_VALUE's !dbg location to know when we need to stop propagating? I was worried that with good value tracking we might carry a stale value forward too far. But writing down the example made me realize that this is more an issue for HowToUpdateDebugInfo.rst than one just local toLiveDebugValues.

If we have the following unoptimized program, with !dbg !1 ~ line 1, etc:

%x = insn1, !dbg !1
DBG_VALUE "v", %x, !dbg !1
insn2, !dbg !2
%y = insn3, !dbg !3
DBG_VALUE "v", %y, !dbg !3
insn4, !dbg !4
%z = insn5, !dbg !5
DBG_VALUE "v", %z, !dbg !5

and it gets optimized to

%y = insn3, !dbg !3
DBG_VALUE "v", %y, !dbg !3
%x = insn1, !dbg !1
DBG_VALUE "v", %x, !dbg !1
insn2, !dbg !2
insn4, !dbg !4 ; now has wrong DBG_VALUE for "v"
%z = insn5, !dbg !5
DBG_VALUE "v", %z, !dbg !5

then insn4 has a stale value for the variable "v", because at location !dbg !4 it should be %y and not %x. We can require all passes to insert a DBG_VALUE undef after moving instructions, or we could start giving debug intrinsics a range of !dbg locations, such as DBG_VALUE "v", %x, [!dbg !1, dbg !3) and define an ordering of !dbg locations.

If we had such a facility: would it be possible to integrate this into the new pass implementation?

-- adrian