A vmerge/vmv.v.v can sometimes be inserting a smaller vector into a larger one,
in which case the underlying vop is obscured underneath COPY_TO_REGCLASS and
INSERT_SUBREG nodes:
t22: nxv4i32 = PseudoVMV_V_V_M2 t42, t38, ...
t38: nxv4i32 = INSERT_SUBREG IMPLICIT_DEF:nxv4i32, t40, TargetConstant:i32<4>
t40: v2i32 = COPY_TO_REGCLASS t41, TargetConstant:i64<22> t41: nxv1i32,ch = PseudoVLE32_V_MF2 ...
This patch extends the fold peephole to handles this case by peeling off these
extra nodes, and then adding back the necessary insert_subreg/extract_subregs:
t48: nxv4i32 = INSERT_SUBREG t42, t47, TargetConstant:i32<4>
t47: nxv1i32,ch = PseudoVLE32_V_MF2_MASK t46, ...
t46: nxv1i32 = EXTRACT_SUBREG t42, TargetConstant:i32<4>
The subregister being inserted into needs to be the bottom subregister, i.e.
index 0.
I'm looking at this, and am trying to understand why we get the COPY_TO_REGCLASS here. If I'm reading this right, we should be generating this only when doing a insert_subreg between two equally LMUL-sized register groups. Given that, I think we must have had two insert_subregs originally, and shouldn't one of have been combined away?