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

Bill Wendling isanbard at gmail.com
Mon Apr 12 17:59:53 PDT 2010


On Apr 12, 2010, at 4:38 PM, Dale Johannesen wrote:

> 
> On Apr 12, 2010, at 4:27 PMPDT, Dan Gohman wrote:
> 
>> 
>> On Apr 12, 2010, at 4:22 PM, Dale Johannesen wrote:
>> 
>>> 
>>> On Apr 12, 2010, at 4:13 PMPDT, Chris Lattner wrote:
>>> 
>>>> 
>>>> On Apr 12, 2010, at 3:19 PM, Bill Wendling wrote:
>>>> 
>>>>> Author: void
>>>>> Date: Mon Apr 12 17:19:57 2010
>>>>> New Revision: 101075
>>>> 
>>>> hi Bill, is it possible for this to go in target independent code, e.g. branch folding?
>>>> 
>>>> -Chris
>>> 
>>> Branch folding is already trying:
>>> 
>>>  // 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?
> 
It does. But it happens too late in the game. The block's not removed until after the "OptimizeBlock" method returns. By then, it goes on to the next block (which happens to be in this case the fall-through of the removed block). Then we're left with the situation this hack fixes.

-bw





More information about the llvm-commits mailing list