Currently TwoAddressInstructions lowers REG_SEQUENCE into a series of subregister defining COPY instructions per input. Not only is REG_SEQUENCE not actually a two address instruction, but this introduces subregister defs that generally are not handled by rematerialization. REG_SEQUENCE should be rematerializable (though it’s not currently marked as such). Why not lower it as a post-RA pseudo along with COPY, instead of before when it can interfere with rematerialization?
The one complication I’ve run into while trying to move this so far is generically lowering the case where the result register overlaps with the inputs, but this seems like a solvable problem. The result should only be able to overlap with killed inputs
I think the current placement stems from the fact that TwoAddressInstructions (and PHIElimination) is the first place within codegen where we drop the Machine-SSA properties and allow multiple definitions for the same vreg. In a sense you can think about REG_SEQUENCE just being a way to model sub-register COPY instructions in an SSA settting.
From an optimization point of view we also lower REG_SEQUENCE into COPYs before the RegisterCoalescing pass so it can optimize those COPYs…
I think the real question is whether it’s easier to spread knowledge through the rest of regalloc about how to optimize and coalesce with REG_SEQUENCE, or whether it’s easier to teach it how to rematerialize nontrivial subregister defs.