As reported in https://github.com/llvm/llvm-project/issues/53584 , there are a few lurking optimisations that don't update debug-info when instructions are mutated (a fairly rare event anyway). When this happens, it's nice to get bug reports, but it's even better for the developer to not crash the compiler and instead ignore any broken variable locations.
To that end, convert assertions about instruction references always referring to register definitions into "if" conditions -- when a non-register-def operand is referred to in transferDebugInstrRef, the variable value will remain "None" and become "optimised out" when seen in a debugger.
I've done the same for DBG_PHIs, and that's exposed a more interesting issue: If there's only ever one DBG_PHI for a value, we don't need to do any further work to determine the instruction references value, it's the one referred to by the DBG_PHI. But:
- If there's more than one DBG_PHI (see value 7 in the added test),
- and one of them is invalid in some way,
- We ignore it, leaving a single DBG_PHI recorded, making the instruction reference value be whatever the remaining DBG_PHI refers to.
In the test below (the DBG_PHIs for value number 7, in blocks 1 and 2), that's undesirable because we essentially ignore the illegal side of the branch in favour of the other. A better solution is to accept that the debug-info is broken, and not produce a variable location. I've implemented that by making the value seen by DBG_PHI Optional, recording None values when a broken DBG_PHI is seen, then producing no variable value from resolveDbgPHIs if any were broken.
I've added some LLVM_DEBUG lines to complain if any of these broken values are seen.
Could you add a sentence to describe the purpose of the test?