similar to: ConstantFoldTerminator doesn't delete trivially dead phi inputs

Displaying 20 results from an estimated 1000 matches similar to: "ConstantFoldTerminator doesn't delete trivially dead phi inputs"

2017 May 01
4
RFC: Stop using redundant PHI node entries for multi-edge predecessors
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
2011 Feb 01
0
[LLVMdev] Loop simplification
Here's what I've got so far - it seems to work, aside from the fact that DeleteDeadPHIs is not removing at least one dead PHI in my test program. --------------------- static bool mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ) { if (succ == pred) return false; if (pred->getFirstNonPHI() != pred->getTerminator()) return false; //
2011 Feb 01
3
[LLVMdev] Loop simplification
On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm
2012 Mar 08
2
[LLVMdev] Updating value from PHI
Here is the code snippet that I am using to create the PHIs in the loop according to the PHIs in the new preheader. At this point I have already redirected the loop backedge and removed the preheader from the loop. for (BasicBlock::iterator II = loopHeaderBB->begin(); (PN=dyn_cast<PHINode>(II)); ++II) { // remove loop back PHI and add it to split BB
2017 May 01
3
RFC: Stop using redundant PHI node entries for multi-edge predecessors
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 creates multiple uses of values in A for no apparently good reason 2) It makes updating PHI nodes using sets of predecessors incredibly hard 3) There is no
2012 Mar 08
0
[LLVMdev] Updating value from PHI
I guess I thought that once I redirected the branches and created new PHIs that LLVM would correct the variable usage when I return true (changed CFG) from the pass. Is this not the case? On Wed, Mar 7, 2012 at 4:08 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Here is the code snippet that I am using to create the PHIs in the loop > according to the PHIs in the new preheader. At
2015 Aug 10
3
Possible bug in adjusting PHINode from removePredecessor?
Hi, Simple description of the problem below. I have code coming into pruneEH as follows fn a { entry: call fn b ... for_cond: %i = phi [1, entry] [%x, for_body] cmp $i with someval cond-br for_body or for_exit for_body: ... $x = $i + 1 branch for_cond for_exit ... } PruneEH determines that the call to fn-b won't return. The code is modified thus. fn a { entry: call fn b unreachable insn
2008 Sep 27
2
[LLVMdev] SwitchInstr::removeCase() doesn't remove PHINodes' predecessors
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
2008 Sep 27
0
[LLVMdev] SwitchInstr::removeCase() doesn't remove PHINodes' predecessors
Nuno Lopes wrote: > PHINode should have one entry for each predecessor of its parent basic > block! > %ret.0 = phi i32 [ 0, %ifthen ], [ 1, %ifelse ] ; <i32> > [#uses=1] > Broken module found, compilation aborted! > > This is because myphi is not reachable from ifthen anymore. My question is: > is this a bug (or missing feature) or do I need to
2018 Jun 29
2
Cleaning up ‘br i1 false’ cases in CodeGenPrepare
> we lower llvm.objectsize later than we should Is there a well-accepted best (or even just better) place to lower objectsize? I ask because I sorta fear that these kinds of problems will become more pronounced as llvm.is.constant, which is also lowered in CGP, gains popularity. (To be clear, I think it totally makes sense to lower is.constant and objectsize in the same place. I'm just
2018 Jun 29
2
Cleaning up ‘br i1 false’ cases in CodeGenPrepare
Hi, I have come across a couple of cases where the code generated after CodeGenPrepare pass has "br i1 false .." with both true and false conditions preserved and this propagates further and remains the same in the final assembly code/executable. In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which handles the br i1 false condition) is called only once and if after the
2012 Mar 08
0
[LLVMdev] Updating value from PHI
I have attached a case of what I am trying to do, I'm pretty sure I'm just missing some simple API call. In the cfg you can see that although Im setting "lsr.iv441" as "lsr.iv44" from for.body.387.i it's not propagating that through the block or graph. On Wed, Mar 7, 2012 at 12:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I am splitting a one BB
2012 Mar 07
4
[LLVMdev] Updating value from PHI
I am splitting a one BB loop into two BB. Basically, the one loop BB has 3 incoming values, one form back edge two from other edges. I want to extract the PHIs from the other two edges out into it's own BB and delete that from the loop, then redirect the backedge to the loopbody (non extracted portion) and create a new PHI coming from the extracted BB and the backedge. I can do this;
2009 Dec 03
2
[LLVMdev] Preserving ProfileInfo in several Passes
Hi all, this (altough a big patch) is actually pretty straight forward: It (tries) to preserve ProfileInfo in all -std-compile-opts passes and all X86-Backend passes. There is still some passes that have corner cases where the ProfileInfo is not correct after the pass. Some passes are still missing... How shall I proceed with this? Andi -------------- next part -------------- A non-text
2017 Apr 28
2
[MemorySSA] A question about how to update the MemorySSA when we call RecursivelyDeleteTriviallyDeadInstructions
When we erase a memory access instruction, existing passes using memory ssa like GVN, NewGVN, GVNHoist and EarlyCSE uses MemorySSAUpdater to do the update before the instruction is erased. However, if we call llvm::RecursivelyDeleteTriviallyDeadInstructions to find out dead instruction recursively and memory access instructions may be erased inside the recursive process, we need a way to update
2009 Dec 03
0
[LLVMdev] Preserving ProfileInfo in several Passes
Hello, Here are a few misc. comments on this patch. Would it make sense to mark the ProfileInfo passes as "CFGOnly?" If so, that would let them be automatically preserved by passes which don't modify the CFG (and that call AU.setPreservesCFG()). > + if (ProfileInfo* PI = getAnalysisIfAvailable<ProfileInfo>()) { > + PI->splitEdge(OrigPreHeader, NewHeader,
2014 Oct 18
2
[LLVMdev] Dereferencing NULL pointer in IndVarSimplify.cpp?
Hi, Here is the code in IndVarSimplify.cpp. SmallVector<WeakVH, 16> DeadInsts; while (!DeadInsts.empty()) if (Instruction *Inst = dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val())) RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI); Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL pointer, the expression,
2009 May 08
2
[LLVMdev] Splitting a basic block, replacing it's terminator
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
2013 Mar 02
2
[LLVMdev] Question about method CodeExtractor::severSplitPHINodes
Hi folks, Hope this is not a silly question. But it bothers me when I am thinking about it. My question is: 1. In the implementation of serverSplitPHINodes(), why it only checks the first PHI node for possible multiple inputs from outside the region to extract. There could be more than one PHI nodes in the header block, and the code only checks the first one. I don't quite get it.
2016 Aug 24
2
LLVM 3.9 RC2's SCCP pass removing calls to external functions?!
Hi Félix, Sanjoy Das wrote: > Félix Cloutier via llvm-dev wrote: > > Assuming that this is a bug, what are the next steps? > > Looks like you already have a very small test case -- have you tried > sticking it in a debugger to see why SCCP thinks removing the call is > okay? > > Alternatively, file a bug at llvm.org/bugs and someone will get to it. The third