[Bug target/82666] [11/12/13/14 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #14 from Jeffrey A. Law --- A better approach might be to to try and create COND_EXPRs for the conditional move in the gimple code. The biggest problem I see with that is the gimple->rtl converters aren't great at creating efficient code on targets without conditional moves. Meaning that we could well end up improving x86, but making several other targets worse. I know this because I was recently poking at a similar problem. We expressed a conditional move of 0, C as a multiply of a boolean by C in gimple. It really should just have been a COND_EXPR, but when we generate that form targets without good conditional move expanders will end up recreating branchy code :(
[Bug target/82666] [11/12/13/14 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666
--- Comment #13 from Andrew Pinski ---
I don't know if this could help here but combine does produce:
Trying 37, 34 -> 38:
37: flags:CCGC=cmp(r82:SI,0x7f)
REG_DEAD r82:SI
34: {r92:DI=r87:DI+r89:DI;clobber flags:CC;}
REG_DEAD r89:DI
REG_UNUSED flags:CC
38: r87:DI={(flags:CCGC>0)?r92:DI:r87:DI}
REG_DEAD r92:DI
REG_DEAD flags:CCGC
Failed to match this instruction:
(set (reg/v:DI 87 [ ])
(plus:DI (mult:DI (gt:DI (reg:SI 82 [ _4 ])
(const_int 127 [0x7f]))
(reg:DI 89 [ _4 ]))
(reg/v:DI 87 [ ])))
I don't know if we could catch this in the backend and split this into 3
instructions if that would do the right thing ...
[Bug target/82666] [11/12/13/14 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #12 from Richard Biener --- GCC 10 branch is being closed.
