This patch is much like patch 1 in this series -- we maintain a collection of where PHI instructions were and their registers, then update that during coalescing. For background on the largest hunk here: CP contains details about a COPY instruction that is being coalesced, where the "Src" register will be merged into the "Dst" register. Src is also referred to as the "RHS", and Dst as "LHS".
This code will quit tracking PHI values if any very complicated subregister coalesces occur -- but I don't believe register coalescing tries that. (I can come up with proof if needs be).
Unrelated to this change, but on the topic of register coalescing, I'd like point out that with DBG_VALUEs, register coalescing is currently breaking variable locations in ways that can only be fixed by instruction referencing. Here's some IR extracted from an LLVM function:
(I don't know how to strip unused metadata,)
And here's the corresponding MIR before PHI Elimination, coalescing, and then after coalescing:
https://gist.github.com/jmorse/3d9972e91cdf94b093f14501a4d14829 https://gist.github.com/jmorse/c45d7f9d5e328018ca884fda6bbde15c https://gist.github.com/jmorse/bbab447ef6e8f9f596fbceabf188cf1e
You can see in the first gist that the DBG_VALUE refers to a PHI; but in the last, it refers to the ADD64ri8, which is wrong. The reason why is that the DBG_VALUE is out of liveness; but its register gets merged with another VReg, resurrecting it with the wrong value. I tried to fix this ages ago with checkMergingChangesDbgValues, but many variable locations get legitimately merged in this way too, so it couldn't drop all of them.
The only way to fix DBG_VALUEs in this pass would be by using control flow information to work out if a coalesces effect on a DBG_VALUE was legitmate or not; or by tracking the value number that the DBG_VALUE originally referred to. Which is effectively what all this instruction referencing work does.