This fixes a bug in the TwoAddressInstruction pass. I work with an out-of-tree target, so I can't provide tests, but this code line was incorrectly handled:
`%vreg3<def,tied1> = subh_a16_a32_aNhDst_formatDstN32 %vreg1:hi16<tied0>, %vreg1:hi16, pred:0, pred:%noreg, pred:0, %CCReg<imp-def,dead>, %cuc<imp-use>; aNh_0_7:%vreg3 aN32_0_7:%vreg1`
it was transformed by TwoAddress into:
`%vreg3<def,tied1> = subh_a16_a32_aNhDst_formatDstN32 %vreg3<tied0>, %vreg3:hi16, pred:0, pred:%noreg, pred:0, %CCReg<imp-def,dead>, %cuc<imp-use>; aNh_0_7:%vreg3`
The problem is with this resulting operand: %vreg3:hi16. Since the transformation coalesced %vreg1 into %vreg3 which is a register of a subregister type, the hi16 should have been removed for the second, untied source operand, just as it was for the first one. (Much later, this gives rise to an assert in VirtRegRewriter.)
There was a bugfix commit 279804 made a year ago that touched the code that handle this and that bugfix I think broke this particular case. My take is that the subregister specification needs to be dropped conditionally, based on whether there was a transformation to a subregister type or not.