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

Reply via email to