[llvm] [DebugInfo][RegisterCoalescer] Drop DBG_VALUEs with unsupported register class (PR #143132)

[Jeremy Morse via llvm-commits]

jmorse wrote:

Hmmm. If I understand correctly, the interests of the register allocator and debug-info are diverging, because:
 * debug-info would like to describe the location of an 8-bit value (within a 32 bit value) as an 8-bit register somewhere, but
 * The register allocator is dealing with a 32 bit value, and expands the register class to any gr32, which might not have describable sub_8bit registers,

is that right?

This does sound problematic; I'm surprised it hasn't appeared in LLVM before. As a first effort, marking such indescribable variable locations as "undef" / optimised-out is fine, but as Matt says the approach in the patch right now is a bit too invasive. A final after-register-coalescing pass over DBG_VALUEs to mark illegal ones undef, or similar, will keep out of the way of other regalloc infrastructure.

A further refinement would be to compile the indescribable variable location into the DIExpression attached to the DBG_VALUE -- adding a mask, or a DW_OP_convert, might represent the illegal subregister index which can't be written in LLVM / MIR.

Thinking in the longer term: there are a number of scenarios in the register allocator that don't fit with debug-infos interests, and typically debug-info "loses" to the register allocator because it's infeasible to make regalloc account for everything debug-info wants to know. Hence, x86_64 (and soon aarch64) use a different "instruction referencing" representation of variable locations which I talked about here [0] (shameless plug) that avoids these issues. There's a good chance that in the next couple of years we'll retire the "DBG_VALUE" model of referring directly to registers with debug instructions. I see the test triple is i386 macos; depending on your level of interest in maintaining variable-locations on that (or other) targets, it's likely better to switch targets over to instruction referencing than to patch up the DBG_VALUE model further.

[0] https://www.youtube.com/watch?v=yxuwfNnp064

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