https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #7 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Before the patch:
Trying 8 -> 14:
8: r113:SI=zero_extend(r117:HI)
REG_DEAD r117:HI
14: r0:SI=r113:SI
REG_DEAD r113:SI
Successfully matched this instruction:
(set (reg/i:SI 0 r0)
(zero_extend:SI (reg:HI 117)))
allowing combination of insns 8 and 14
original costs 4 + 2 = 6
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i3 14: r0:SI=zero_extend(r117:HI)
REG_DEAD r117:HI
deferring rescan insn with uid = 14.
After:
Trying 8 -> 14:
8: r113:SI=zero_extend(r117:HI)
REG_DEAD r117:HI
14: r0:SI=r113:SI
REG_DEAD r113:SI
Successfully matched this instruction:
(set (reg/i:SI 0 r0)
(and:SI (subreg:SI (reg:HI 117) 0)
(const_int 1 [0x1])))
allowing combination of insns 8 and 14
original costs 4 + 2 = 6
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i3 14: r0:SI=r117:HI#0&0x1
REG_DEAD r117:HI
deferring rescan insn with uid = 14.
So with the same inputs, combine makes a different decision, I guess that's
because it has some knowledge that reg:HI 117 is the result of a comparison
rather than an unspec.
