search for: removepredecessor

Hi all, for(pred_iterator PI=pred_begin(BB); PI!=pred_end(BB); PI++) { BasicBlock *Pres = *PI; pred.insert(Pres); } for(predit = pred.begin(); predit!=pred.end();predit++) (BB)->removePredecessor(*predit); Is this code enough to remove the predecessor for each basic block As I read in documentation that this removePredecessor() doesn't update the predecessor list. So, how could I update the predecessor list ? Is it also by changing the terminator instruction of the predecessor? Than...

...path from entry block */ cmp $x with someval cond-br for_body or for_exit for_body: ... $x = $x + 1 branch for_cond for_exit ... } The instruction $x = $x + 1 is obviously illegal in SSA form, which shows up as an infinite loop in value numbering. The source of the problem exists in BasicBlock::removePredecessor function in BasicBlock.cpp. The comment in that function describes this exact scenario // If there are exactly two predecessors, then we want to nuke the PHI nodes // altogether. However, we cannot do this, if this in this case: // // Loop: // %x = phi [X, Loop] // %x2 = add %x, 1...

I'm looking into some missed optimizations where CodeGenPrepare seems to leave trivially dead instructions lying around. This happens because CodeGenPrepare::runOnFunction calls ConstantFoldTerminator which folds a "br i1 false" into an unconditional branch and calls BasicBlock::removePredecessor which calls PHINode::removeIncomingValue. Each incoming value that is removed from a phi node might be dead now, but nothing deletes them. Is there any way this could be improved? Could PHINode::removeIncomingValue call RecursivelyDeleteTriviallyDeadInstructions on the value it removes, or is that...

...PHI > Nodes myself? You get to take care of it yourself. If it is the later what's the best way to handle that? (from > what I could see I would need to iterate over all the instructions in the > target BB and fix PHI Nodes if the target block becomes unreachable). TargetBB->removePredecessor(SwitchBB). Note that you should call this before you call removeCase! Nick

Hi, I want to insert a conditional branch in the middle of a basic block. To that end, I am doing these steps: (1) Split the basic block: bb->splitBasicBlock() (2) Remove the old terminator: succ->removePredecessor(bb) bb->getTerminator()->getParent() (3) Adding a new terminator: BranchInst::Create(ifTrue, ifFalse, cnd, "", bb); That seems to work, but later passes are dieing. When I dump the function from my debugger, I notice that the new block (the second half of the block I split) has...

Hi, I've been writing an optimization pass (described on the ML previously). Sometimes this pass removes some case entries from switch instructions, which cause an abort because removeCase() doesn't fix the PHINodes predecessors when needed. e.g.: define i32 @foo() nounwind { ifthen: %call = call i32 @bar() switch i32 %call, label %myphi [ i32 0, label %ifelse i32 1, label

On May 8, 2009, at 4:02 PM, Nick Johnson wrote: > I want to insert a conditional branch in the middle of a basic block. > To that end, I am doing these steps: > > (1) Split the basic block: > bb->splitBasicBlock() > > (2) Remove the old terminator: > succ->removePredecessor(bb) > bb->getTerminator()->getParent() Assuming that the new block will still be a successor of the old block (just not the unique successor), all you really need to do is: BasicBlock* succ = bb->splitBasicBlock(); bb->getTerminator()->eraseFromParent(); BranchInst::Cre...

...cessors() && "Trying to remove a nonexistant successor!"); // If our old successor block contains any PHI nodes, remove the entry in the // PHI nodes that comes from this branch... // BasicBlock *BB = TI->getParent(); TI->getSuccessor(SuccNum)->removePredecessor(BB); TerminatorInst *NewTI = 0; switch (TI->getOpcode()) { case Instruction::Br: // If this is a conditional branch... convert to unconditional branch. if (TI->getNumSuccessors() == 2) { cast<BranchInst>(TI)->setUnconditionalDest(TI->getSuccessor(1-Suc...

Hi, On Mon, May 1, 2017 at 8:47 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Today, the IR requires that if you have multiple edges from A to B >> (typically with a switch) any phi nodes in B must have an equal number of >> entries for A, but that all of them must have the same value. > >> This seems rather annoying.... >> 1) It

Hi, I am working with regular dominator tree and not MachineDominatorTree. I wanted to modify the CFG structure and for that I need to change successor of a basic block. How can I do that? Or is there a way to cast a BasicBlock to MachineBasicBlock so that i can use functions addSucessor and removeSuccessor for the basic block. It will be great if someone can help. regards, Ambika

OK. Thanks. And if I removed "case 4:" for example. Need I scan all phi nodes and fix it, by removing one predecessor (if it exists) to switch's parent block? -Stepan. Nick Lewycky wrote: > Stepan Dyatkovskiy wrote: >> Hi all. >> >> Looking at test/Transforms/LoopUnswitch/preserve-analyses.ll, I found >> improper phi instruction at string #122: >>

Hello everyone, I've been having discussions with Jakub Kuderski about the merits of having routines to think more about the shape of the CFG instead of dealing with the details of the IR. I have one such patch posted and would like to know what the larger community thinks of the idea. The patch is here: <goog_558917248> https://reviews.llvm.org/D37575 This patch adds a routine