(Context: the patch series' at D83046 and D85741). This series tracks PHI instructions through register allocation -- which in the original RFC, I wrote:
"My understanding is that the register allocation phase of LLVM starts there [phielim] and ends after virtregrewriter, and it'd be legitimate to say "we do special things for these passes"."
This patch introduces the "special things": in PHI Elimination we record the position of any PHI instruction that is eliminated, its register and debug instruction number. The register is updated through register allocation; and afterwards, we emit a 'DBG_PHI' instruction identifying the physreg / stack slot where the PHI occurs.
An example of the DBG_PHI instruction working would be:
bb1: DBG_PHI $rax, 1 [... more insts ... ] bb2: DBG_INSTR_REF 1, 0
The DBG_PHI identifies the position at which the PHI occurs ($rax here) for debug instruction 1, which can then be picked up by instruction-referencing LiveDebugValues, and tracked until a DBG_INSTR_REF instruction uses that debug instruction number.
This may look a bit like a DBG_VALUE, but it isn't: by using two instructions, we've separated two really important parts of variable value tracking:
- Where the machine value comes from (specified by DBG_PHI),
- Where the machine value becomes the variables value.
For PHI instructions, we absolutely need a program point to identify the machine value: that's the nature of PHIs. Thus, to track PHI values, we need to put a new instruction to identify where the PHI occurs.
In this particular patch, I've added boilerplate for the DBG_PHI instruction, some data structures in MachineFunction to track PHIs during regalloc, and code in LiveDebugVariables to update locations when virtual registers are split plus emit DBG_PHIs afterwards. In the other two patches:
- Register coalescing
- Handling this all in LiveDebugValues
maintenance.