search for: removebranch

...> BX %R6<kill> > > Inside the *IfConvertDiamondCommon(...)* function of IfConversion.cpp, > the function is called with *NumDups2=1*, which makes sense because BB#8 > and BB#9 share the same *LDRrs* instruction with the same operands. The > problem is the call to *TTI->removeBranch(...)* function that does not > remove the *BX* instruction. Thus, when removing the common instructions, > the *BX* is removed instead of the *LDRs* instruction. > > # Before removeBranch call on MBB1 > BB#9: derived from LLVM BB %if.else.i.i.i.i > Live Ins: %LR %R0 %R1 %R2 %R4...

..., pred:%noreg; mem:LD4[%0] > BX %R6<kill> Inside the _IfConvertDiamondCommon(...)_ function of IfConversion.cpp, the function is called with _NumDups2=1_, which makes sense because BB#8 and BB#9 share the same _LDRrs_ instruction with the same operands. The problem is the call to _TTI->removeBranch(...)_ function that does not remove the _BX_ instruction. Thus, when removing the common instructions, the _BX_ is removed instead of the _LDRs_ instruction. > # Before removeBranch call on MBB1 > BB#9: derived from LLVM BB %if.else.i.i.i.i > Live Ins: %LR %R0 %R1 %R2 %R4 %R5 %R6 %R7 %R8...

...identical instruction in step 1) JUMP <BB#3>, pred:%noreg 3) try to remove branches, starting with JUMP <BB#4>, pred:%p387 inserted in step 3). That is when things go wrong and I get the following assertion (with GDB) backtrace. (Please note that my RemoveBranch code is nothing special, it looks exactly the same as the code in the Mips backend. ) llc: /work/llvm/trunk/llvm/lib/CodeGen/MachineRegisterInfo.cpp:162: void llvm::MachineRegisterInfo::removeRegOperandFromUseList(llvm::MachineOperand*): Assertion `NextOp->getReg() == MO->getReg() &&...

...e LBB0_34 though. It would be interesting to see the blocks before and after the "Basic block placement" pass. Running llc with -print-after-all and/or -debug might well shed some light on what's happening. Other possible bugs are in implementations of AnalyzeBranch, InsertBranch or RemoveBranch. They're target callbacks LLVM uses to do its more invasive block movement. The place to start debugging is lib/CodeGen/MachineBlockPlacement.cpp. Something in there is probably getting confused. Cheers. Tim.

Hi, guys, I compiled a subroutine with -O2, and llvm backend produced codes like: ################################################################## LBB0_32: ... R31 = -1 R20 = R31 * R20; .... bnz R2, LBB0_34 LBB0_31: ... b LBB0_34 LBB0_33: # weird basic block? R20 = R5 LBB0_34: ....

Is LiveVariables updated correctly when TII->RemoveBranch and TII->InsertBranch are called in the following piece of code? - MachineBasicBlock::updateTerminator() line 307 of MachineBasicBlock.cpp: if (FBB) { // The block has a non-fallthrough conditional branch. If one of its // successors is its layout successor, rewrite it to a fallth...

...e the condition. These operands can be used to create new + /// branches. + /// 6. If the block ends with a conditional return followed by an + /// unconditional branch, the 'false' destination is FBB, while TBB is + /// null. Cond is non-empty as above. /// /// Note that RemoveBranch and InsertBranch must be implemented to support /// cases where this method returns success. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160531/b7086d8b/attachment.html> -------------- next part ---...

Hi All, For various obscure reasons I'd like to detect the condition when X86 CALL instruction immediately precedes a function epilogue in the final emitted code, and insert a NOP between them if that happens. My initial attempt at it looked like this: MachineBasicBlock& MBB; MachineBasicBlock::iterator MBBI; <-- points to where the epilogue would be inserted if (MBBI != MBB.begin()

...gt; conditional_branch <BB#3> Successors according to CFG: BB#3 So this is not a loop any more. Instead, a branch needs to be inserted to replace the implicit fall-through in BB#1. I have attached a patch for this. (Incidentally, I see a duplication of the statement "TII->removeBranch(*PrevBB);" if run after register allocation. I've removed this call in the patch as well.) Unfortunately, I am working on a proprietary target, so cannot provide a test case. I have, however, attached a "pseudo mir" which should be easily adaptable for a public target. Maybe...

On Wed, Oct 31, 2012 at 09:13:43PM +0100, Bjorn De Sutter wrote: > Hi all, > > I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we

...re are also other related instructions). I started this process by converting the Hexagon Hardware-Loops pass to work with analogous PPC instructions. This worked fairly well, but left a bunch of unneeded unconditional branches. To fix this, I added support into AnalyzeBranch (and InsertBranch and RemoveBranch). Unfortunately, this really broke things, the branch instructions (which both used and defined the count register) were moved around in invalid ways causing both compile-time (live-out assertions) and run-time failures. Instead of trying to track down these problems, I thought it would be better t...

Hi all, I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we support or, and, and conditional predicates (see Scott Mahlke's papers on this