[llvm-commits] [llvm] r101075 - in /llvm/trunk: lib/Target/X86/X86InstrInfo.cpp test/CodeGen/X86/brcond.ll

Chris Lattner clattner at apple.com
Mon Apr 12 17:18:48 PDT 2010


>>>  // If the prior block branches here on true and somewhere else on false, and
>>>  // if the branch condition is reversible, reverse the branch to create a
>>>  // fall-through.
>>>  if (PriorTBB == MBB) {
>>>    SmallVector<MachineOperand, 4> NewPriorCond(PriorCond);
>>>    if (!TII->ReverseBranchCondition(NewPriorCond)) {
>>>      TII->RemoveBranch(PrevBB);
>>>      TII->InsertBranch(PrevBB, PriorFBB, 0, NewPriorCond);
>>>      MadeChange = true;
>>>      ++NumBranchOpts;
>>>      goto ReoptimizeBlock;
>>>    }
>>>  }
>>> 
>>> Why doesn't it work in this case?
>> 
>> I was curious too. CodeGenPrepare has split a critical edge for a PHI
>> node, however after register allocation it turns out that no copy was
>> needed, so the jmp is actually in a separate basic block from the
>> jne, jp.
> 
> 
> In that case, branch folding should be removing the block that consists of only an unconditional branch:
> 
>      // If this block is just an unconditional branch to CurTBB, we can
>      // usually completely eliminate the block.  The only case we cannot
>      // completely eliminate the block is when the block before this one
>      // falls through into MBB and we can't understand the prior block's branch
>      // condition.
>      if (MBB->empty()) {
>         <too long to quote, but appears to do what the comment says>
> 
> so why doesn't *that* work?
> 

I think that answering these questions (and fixing the problem) is a much better idea than hacking the X86 backend to handle one specific case of this.

-Chris



More information about the llvm-commits mailing list