https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94687
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-04-30
Status|UNCONFIRMED |NEW
CC| |segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Confirmed.
At combine time we start with
insn_cost 4 for 25: r130:V1TI=%2:V1TI
REG_DEAD %2:V1TI
insn_cost 4 for 20: r129:V1TI=r130:V1TI
REG_DEAD r130:V1TI
insn_cost 4 for 21: r127:DI=r129:V1TI#0
insn_cost 4 for 22: r128:DI=r129:V1TI#8
REG_DEAD r129:V1TI
insn_cost 4 for 24: r123:TI=0
insn_cost 4 for 7: r123:TI#8=r127:DI
REG_DEAD r127:DI
insn_cost 4 for 8: r123:TI#0=r128:DI
REG_DEAD r128:DI
insn_cost 4 for 9: r122:V1TI=r123:TI#0
REG_DEAD r123:TI
insn_cost 4 for 14: %2:V1TI=r122:V1TI
REG_DEAD r122:V1TI
insn_cost 0 for 15: use %2:V1TI
and those subregs at the lhs (insns 7 and 8) cannot combine with anything.
2-to-2 combine won't handle 20+21 (and then, 20+22) because 20 is a register
move already. It would probably combine fine if that subreg lhs problem was
fixed though.
