[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