https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |85559 --- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Biener from comment #8) > (In reply to Jakub Jelinek from comment #6) > > So pretty much undo all ifcvt into conditional moves (aka pretend the target > > doesn't have cmov) or something else? > > The problem is that cmov isn't unconditionally bad or unconditionally good > > and moving in either direction usually results in significant regressions. > > cmov is good if the branch will be often badly predicted, so when the branch > > prediction is close to 50%, and is bad when it is usually well predicted. > > I'd only do it for MAX<small-constant, x> and MIN<large-constant, x>. > There's > also another conditional move a few instructions up, not sure if cmove > density would be another thing to key on. And if I read the refrenced PR56309 then the issue might be that for cmpl %eax, %esi cmovge %esi, %eax movl %ecx, %esi cmpl %ebx, %eax cmovl %ebx, %eax the second compare uses the cmov destination. But todays micro architectures are too complex to really tell what the issue is (still constraining a peephole quite strictly could be possible, on either or both of the patterns that appear here). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85559 [Bug 85559] [meta-bug] Improve conditional move