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

[Bill Wendling]

On Apr 12, 2010, at 5:18 PM, Chris Lattner wrote:

>>>> // 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.
> 
I looked into all of this, but it wouldn't work for various reasons (it was several weeks ago so I forget most of the reasons, but Dan discovered one of them).

I'll look again.

-bw