[llvm] r258847 - Allow X86::COND_NE_OR_P and X86::COND_NP_OR_E to be reversed.

[Xinliang David Li via llvm-commits]

On Wed, Jan 27, 2016 at 4:41 AM, Benjamin Kramer via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> This also breaks compiling code with
>
> >  fatal error: error in backend: Undefined temporary symbol
>
> will revert and follow up with a test case.
>
>
thanks -- can you follow up with a test case?

David

> On Wed, Jan 27, 2016 at 5:11 AM, James Knight via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> > This change is broken in some fashion; it causes llvm to rewrite
> branches incorrectly producing an infinite loop.
> >
> >> On Jan 26, 2016, at 3:08 PM, Cong Hou via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> >>
> >> Author: conghou
> >> Date: Tue Jan 26 14:08:01 2016
> >> New Revision: 258847
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=258847&view=rev
> >> Log:
> >> Allow X86::COND_NE_OR_P and X86::COND_NP_OR_E to be reversed.
> >>
> >> Currently, AnalyzeBranch() fails non-equality comparison between
> floating points
> >> on X86 (see https://llvm.org/bugs/show_bug.cgi?id=23875). This is
> because this
> >> function can modify the branch by reversing the conditional jump and
> removing
> >> unconditional jump if there is a proper fall-through. However, in the
> case of
> >> non-equality comparison between floating points, this can turn the
> branch
> >> "unanalyzable". Consider the following case:
> >>
> >> jne.BB1
> >> jp.BB1
> >> jmp.BB2
> >> .BB1:
> >> ...
> >> .BB2:
> >> ...
> >>
> >> AnalyzeBranch() will reverse "jp .BB1" to "jnp .BB2" and then "jmp
> .BB2" will be
> >> removed:
> >>
> >> jne.BB1
> >> jnp.BB2
> >> .BB1:
> >> ...
> >> .BB2:
> >> ...
> >>
> >> However, AnalyzeBranch() cannot analyze this branch anymore as there
> are two
> >> conditional jumps with different targets. This may disable some
> optimizations
> >> like block-placement: in this case the fall-through behavior is
> enforced even if
> >> the fall-through block is very cold, which is suboptimal.
> >>
> >> Actually this optimization is also done in block-placement pass, which
> means we
> >> can remove this optimization from AnalyzeBranch(). However, currently
> >> X86::COND_NE_OR_P and X86::COND_NP_OR_E are not reversible: there is no
> defined
> >> negation conditions for them.
> >>
> >> In order to reverse them, this patch defines two new CondCode
> X86::COND_E_AND_NP
> >> and X86::COND_P_AND_NE. It also defines how to synthesize instructions
> for them.
> >> Here only the second conditional jump is reversed. This is valid as we
> only need
> >> them to do this "unconditional jump removal" optimization.
> >>
> >>
> >> Differential Revision: http://reviews.llvm.org/D11393
> >>
> >>
> >>
> >> Modified:
> >>    llvm/trunk/lib/Target/X86/X86InstrInfo.cpp
> >>    llvm/trunk/lib/Target/X86/X86InstrInfo.h
> >>    llvm/trunk/test/CodeGen/X86/block-placement.ll
> >>    llvm/trunk/test/CodeGen/X86/fast-isel-cmp-branch2.ll
> >>    llvm/trunk/test/CodeGen/X86/fast-isel-cmp-branch3.ll
> >>    llvm/trunk/test/CodeGen/X86/fp-une-cmp.ll
> >>
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160127/9a4fdd77/attachment-0001.html>