[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 --- Comment #7 from Uroš Bizjak --- (In reply to Andrew Pinski from comment #2) > Note for some x86 cores having 2 or more cmove back to back is worse than a > conditional jump so maybe the testcase is now catching what it should happen > ... Please see PR85559 meta bug and PR56309. Some heuristic should be developed when to use CMOV insn. Some analysis is at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073#c16
[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 --- Comment #6 from Jeffrey A. Law --- And just an FYI, the tester is flagging conditional move failures for mips64-* rx-elf and s390-linux-gnu. Most likely these are additional cases where the hook is indicating the transformation isn't profitable, but the target tests are expecting the transformation to happen. I'll debug those other targets and take appropriate action. At this point I don't see anything that would strongly suggest reversion of the patch, just that we need a bit of testsuite adjustment.
[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-04-19
--- Comment #5 from Jeffrey A. Law ---
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.
[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 --- Comment #4 from Jeffrey A. Law --- x86's tuning does have some support for avoiding multiple cmovs in a single if-converted sequence. I'll double check if that's kicking in here.
[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I see both +FAIL: gcc.target/i386/cmov6.c scan-assembler cmov[^6] +FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6 on x86_64-linux, while only the former on i686-linux.
[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail Target||x86_64-*-* Target Milestone|--- |14.0
[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 --- Comment #2 from Andrew Pinski --- Note for some x86 cores having 2 or more cmove back to back is worse than a conditional jump so maybe the testcase is now catching what it should happen ...
[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 --- Comment #1 from Andrew Pinski --- > BTW, I saw Andrew's patch fixing cmov: It is unrelated. This is a cost model issue of the x86 backend I think.
