[llvm] [LiveDebugVariables] Add basic verification (PR #68703)

[Jeremy Morse via llvm-commits]

jmorse wrote:

This fell off my radar, sorry. Thanks for the background on what's going on here, FTR, this patch LGTM. Note that there are two flavours of debug-info format in the CodeGen pipeline and the records you're verifying only addresses one of them, there's also a collection that contains SlotIndexes in StashedDebugInstrs and PHIValToPos that you might want to verify too.

I had a look at one of the failures (spill-indirect-nrvo.ll), and it would appear that:
 * We split a virtual register location with a COPY,
 * LiveDebugVariables updates it's mappings to record the new location at the position of the copy, with vreg %7
 * InlineSpiller::spill comes along and spills the value, making the COPY a dead definition (apparently),
 * The mapping of slot-index to vreg %7 continues on in LiveDebugVariables,
 * When VirtRegRewriter comes along and emits DBG_VALUE instructions, in UserValue::rewriteLocations, vreg %7 which isn't otherwise defined has a stack location looked up by VRM.getStackSlot. As it's the same location as earlier DBG_VALUEs, they get coalesced together (I think) and the dead slot index doesn't get used.

This feels like an error where, by chance, the right thing happens most of the time. I've got various feelings on solutions:
 * We could rewrite all the location-mappings at the end of regalloc to ensure illegal slotindexes get coalesced away early,
 * We could explicitly signal from the regalloc code that a definition is being deleted.

As far as I'm aware LiveDebugVariables doesn't have any concept of "this assignment is just going to completely go away", LiveRangeEdit::eliminateDeadDef would have to be updating LiveDebugVariables to let it know. I'm not sure how we'd then update the variable location data in that circumstance.

CC @felipepiovezan as we won't be seeing this on X86 as it uses the other CodeGen debug-info format, but it could be an issue that arm-like systems see.

https://github.com/llvm/llvm-project/pull/68703