In todays episode of "uncommon corner cases that LiveDebugValues handles": overlapping fragments. The modified test checks that if we have a variable where its fragments are split into overlapping segments:
DBG_VALUE $ax, $noreg, !123, !DIExpression(DW_OP_LLVM_fragment_0, 16) ... DBG_VALUE $eax, $noreg, !123, !DIExpression(DW_OP_LLVM_fragment_0, 32)
that we only propagate the most recently assigned fragment out of a block. The test only deals with live-in variable locations, as overlaps within blocks is DbgEntityHistoryCalculators domain.
InstrRefBasedLDV needs to preserve this behaviour: we've kept the accumulateFragmentMap method from VarLocBasedLDV, we just need it to recognise DBG_INSTR_REFs. Once it's produce a mapping of variable / fragments to the overlapped variable / fragments, VLocTracker uses it to identify when a debug instruction needs to terminate the other parts it overlaps with.
The changes to live-debug-values-fragments.mir are:
- $ax switches to $cx in two scenarios, because it's a value copied from one register to another, doesn't matter which is used,
- The order of DBG_VALUEs produced changes with instruction referencing.
See other comment re: inlined-at and overlaps. Because of how the overlap map is constructed I think you're going to be treating fragments of 2 inlined instances of a variable as overlapping here. If I'm correct about that, I think the fix should be in how the overlap map is constructed (see other comment).