https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-04-19
--- Comment #5 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Yea, that's exactly what's kicking in here. The converted sequence looks like
this:
(insn 29 0 28 (set (reg:SI 86)
(const_int 10 [0xa])) 83 {*movsi_internal}
(nil))
(insn 28 29 30 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 83 [ c ])
(const_int 0 [0]))) 7 {*cmpsi_ccno_1}
(nil))
(insn 30 28 32 (set (reg/v:SI 85 [ e ])
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 85 [ e ])
(reg:SI 86))) 1318 {*movsicc_noc}
(nil))
(insn 32 30 31 (set (reg:SI 87)
(const_int 20 [0x14])) 83 {*movsi_internal}
(nil))
(insn 31 32 33 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 83 [ c ])
(const_int 0 [0]))) 7 {*cmpsi_ccno_1}
(nil))
(insn 33 31 0 (set (reg/v:SI 84 [ d ])
(if_then_else:SI (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 84 [ d ])
(reg:SI 87))) 1318 {*movsicc_noc}
(nil))
Note the two movsicc_* patterns.
So the question now is what to do about it. It looks like things are behaving
as expected, so my first inclination would be to adjust the test. Actually
splitting it into two would likely be even better. One would verify that by
default we do not generate a pair of cmovs for this code, the other would turn
the tuning bit off and verify that we do generate the pair of cmovs.
Happy to do whatever the x86 maintainers want here.
