[llvm] r258847 - Allow X86::COND_NE_OR_P and X86::COND_NP_OR_E to be reversed.
James Knight via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 26 20:11:14 PST 2016
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
>
More information about the llvm-commits
mailing list