This patch implements the proposals in the RFC made earlier this year.
This patch makes two notable changes to the MIR debug info representation, which result in different MIR output but identical final DWARF output (NFC w.r.t. the full compilation). The two changes are:
- The introduction of a new MachineOperand type, MO_DbgInstrRef, which consists of two unsigned numbers that are used to index an instruction and an output operand within that instruction, having a meaning identical to first two operands of the current DBG_INSTR_REF instruction. This operand is only used in DBG_INSTR_REF (see below).
- A change in syntax for the DBG_INSTR_REF instruction, shuffling the operands to make it resemble DBG_VALUE_LIST instead of DBG_VALUE, and replacing the first two operands with a single MO_DbgInstrRef-type operand.
Combined, these changes do not affect anything about the debug info that we produce or how we handle it throughout CodeGen, but instead simply changes the way we represent instruction references:
Old: DBG_INSTR_REF 1, 0, !123, !456 New: DBG_INSTR_REF !123, !456, dbg-instr-ref(1, 0)
The motivation for this, as described in the RFC, is that we wish to be able to use instruction references in variadic debug values. One of the key difficulties with variadic debug values is that they must track the lifetimes of every register that they refer to, making them brittle to things like hoisting or sinking instructions - even if there is a valid range where a variadic debug value can be computed, the debug value may be terminated by shuffling instructions. As instruction references are more resilient against this sort of thing by referring to values produced by instructions instead of registers, freeing us from the need to move the debug values themselves around and preemptively terminate their ranges, it may be beneficial to allow variadic debug values to take advantage of this behaviour.
This patch does not grant this functionality, but takes care of all the foundational work to implement this feature, allowing the next patch to focus entirely on functional changes.
Un-necessary move of the label -- quite a nit, but future code archeologists looking at git blame will appreciate it not having been moved.