Yes! But the exact timescale is unclear, unfortunately it counts as a side-project and isn’t a main focus with my employer right now. I made a small attempt at it a few months ago, the code for which is at [0], however it’s pre-prototype not-production-ready not-testable and not-fully-working.
In principle, exactly the same design can be applied in MachineIR as we used in LLVM-IR, i.e. adding a bit to the iterator class to record whether a position is before-or-after debug records. The code at [0] turns some of the relevant classes into templates for LLVM-IR/MachineIR, and experiments with converting through instruction-selection. All the same concepts transfer: however there are two ways to represent variable locations MachineIR, and one of them does require debug-info to be in instructions.
Variable assignments represented with a DBG_VALUE instruction referring to a virtual register, i.e.
DBG_VALUE %0, $noreg, !123, !DIExpression(), ...
Have a Register MachineOperand that I believe can be part of a use-list. If we move variable location information out of MachineInstrs but preserve these vreg references, then debug-info concerns will be pushed into other parts of the codebase. Code would need to be aware when iterating register uses that it might come upon a debug-record, not an instruction.
The alternative “instruction referencing” [1] way of encoding variable locations doesn’t have virtual register references, and defers producing register locations til the LiveDebugValues pass. We would be able to move its DBG_INSTR_REF records out of MachineInstrs with no extra thought, as they require no direct maintenance during the rest of compilation. There’s also a DBG_PHI instruction that has to refer to physical registers, but that’s a much smaller problem and can be worked around.
So far instruction referencing is enabled on x86 only, where it’s working well. It might come to aarch64 soon (cc @rastogishubham ). To remove debug-instructions from MachineIR we would have to deprecate the DBG_VALUE-of-virtual-register mechanisms which would force some work onto other backends: I haven’t put any thought into doing this yet.
[0] GitHub - jmorse/llvm-project at ddd-post-isel
[1] Instruction referencing for debug info — LLVM 22.0.0git documentation