Peephole optimizer should not be introducing sub-reg definitions
as they are illegal in machine SSA phase. This patch modifies
the optimizer to not emit sub-register definitions.
|343–344 ↗||(On Diff #348973)|
Can this be conditional so we don't change the behaviour of the common case?
if (unsigned SubIdx = Def.getSubReg()) DefinedLanes = TRI->composeSubRegIndexLaneMask(SubIdx, DefinedLanes);
I'm not sure this is the right fix.
From my understanding, REG_SEQUENCE, INSERT_SUBREG, EXTRACT_SUBREG, and PHI should never target a subregister. For COPY, we can target a subregister, but only if that register is a physical register. So this patch only affects COPY instructions.
Given that, I think we should be bailing out sooner; trying to understand subregister defs of physical registers seems tricky, and not really related to the purpose of this pass.
It certainly does sound odd to have a subreg on a def of a virtual register in SSA. We'll see where this is coming from and why but just a quick look at the -print-after-all output reveals that it is the peephole optimizer that produces it. We'll look into whether this is a bug in the peephole optimizer or if this is some PPC callback called from the peephole optimizer that does this.
I don't see why you need to special case the use opcode
The SubIdx should not be passed through here?
IR section is not necessary
Should use a relevant name and add a descriptive comment
Registers section not necessary