https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> ---
One of the first things combine tries is
Trying 7 -> 8:
7: r96:SI=r104:SI&0xe
REG_DEAD r104:SI
8: r99:DI=sign_extend(r96:SI)
...
Successfully matched this instruction:
(set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
(const_int 14 [0xe])))
Successfully matched this instruction:
(set (reg:DI 99 [ a ])
(and:DI (subreg:DI (reg:SI 104) 0)
(const_int 14 [0xe])))
allowing combination of insns 7 and 8
original costs 4 + 4 = 8
replacement costs 4 + 4 = 8
modifying insn i2 7: r96:SI=r104:SI&0xe
deferring rescan insn with uid = 7.
modifying insn i3 8: r99:DI=r104:SI#0&0xe
REG_DEAD r104:SI
deferring rescan insn with uid = 8.
Since combine is a greedy optimisation, what it ends up with depends on the
order it tries things in. Any local minimum it finds can prevent it from
finding a more global minimum. In that sense, this is not a regression.
How do you propose we could generate better code for this case? Without
regressing everything else.
