https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110811
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Last reconfirmed| |2023-07-26
Target| |x86_64-*-*
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. combine "duplicates" the multi-use:
Trying 9 -> 11:
9: r90:QI=flags:CCNO>0
REG_DEAD flags:CCNO
11: r91:SI=zero_extend(r90:QI)
Successfully matched this instruction:
(set (reg:QI 90)
(gt:QI (reg:CCNO 17 flags)
(const_int 0 [0])))
Successfully matched this instruction:
(set (reg:SI 91 [ t ])
(gt:SI (reg:CCNO 17 flags)
(const_int 0 [0])))
allowing combination of insns 9 and 11
original costs 4 + 4 = 8
replacement costs 4 + 4 = 8
modifying insn i2 9: r90:QI=flags:CCNO>0
deferring rescan insn with uid = 9.
modifying insn i3 11: r91:SI=flags:CCNO>0
REG_DEAD flags:CCNO
but reg:QI 90 is still live:
(insn 13 12 14 2 (set (reg:DI 92 [ _1 ])
(zero_extend:DI (reg:QI 90))) "t.c":6:7 166 {zero_extendqidi2}
(expr_list:REG_DEAD (reg:QI 90)
(nil)))
in the end it's a backend costing issue - we cost the setcc the same as
the zero_extend?