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
