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?