[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