similar to: Is a PHI use of another PHI in the same block valid?

If we decide not to be legal, should we change the verify to reject it? What happens to the test cases that currently test this very situation (eg. Transforms/LoopVectorize/phi-hang.ll)? The change as suggested by Philip is: - Assert(InstsInThisBlock.count(Op) || DT.dominates(Op, U), + Assert((!isa<PHINode>(I) && InstsInThisBlock.count(Op)) || + DT.dominates(Op, U), +

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 trying to undo some of the loop optimizations that LLVM has applied to my program to reduce a pair of nested loops to a single loop.

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

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

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

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 trying to undo some of the loop > optimizations that LLVM has applied to my

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;

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

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; //

So my best bet is to try and work in reg2mem mode and then go back to mem2reg? I'm curious, it seems though when you split a block that the phis get updated, right? On Thu, Feb 2, 2012 at 5:05 PM, Eric Christopher <echristo at apple.com> wrote: > Not that I'm aware of. > > -eric > > On Feb 2, 2012, at 3:47 PM, Ryan Taylor wrote: > > So essentially I'm

On Mon, Jun 29, 2015 at 10:16 AM, Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> wrote: > Hi Anirudh, > > > > I hope these lecture slides about SSA and the dominance frontier will help > you with SSA and control flow analysis: > > > > http://www.seas.harvard.edu/courses/cs252/2011sp/slides/Lec04-SSA.pdf > > > > Unfortunately a use of

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Feb 6, 2012 at 10:36 AM Subject: Re: [LLVMdev] Updating PHI for Instruction Domination? To: Eric Christopher <echristo at apple.com> Since I'm not sure which instructions I might want to replicate, would it be possible to cast the Value from "PHINode::getIncomingValue" to

Hi! I'm having some trouble with a pass I'm writing. I'm using DemotePHIToStack to remove all phi node in my code with this code (this is the first thing I do in my pass): // Erase phi node vector<PHINode*> phis; for (Function::iterator i=f->begin();i!=f->end();++i) { for(BasicBlock::iterator b=i->begin();b!=i->end();++b) {

In your original file, %6 is defined in if.end11 and is used in cond.end. if.end11 branches to cond.true and cond.false, both of which branch unconditionally to cond.end. Therefore %6 dominates its use. In your second file %18 is defined in end.11 and used in cond.end. However, end.11 no longer dominates cond.end because you have rewritten all branches to go through the switch statement in

Hello, I have one more question about how phi nodes and their corresponding ICmp instructions are associated. maybe it is simple, but at first I thought that we always compare against one of incoming value. Is it true that I can have only two cases: %indvars.iv = phi i64 [ %indvars.iv.next, %1 ], [ 0, %0 ] ... %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1 %exitcond = icmp eq i64

On 08/20/2012 03:46 PM, Duncan Sands wrote: > Hi Andrew, > >> Somewhere during optimization PHI nodes on pointer types (including >> alloca instructions) are being introduced, and they persist through the >> scalar replacement of aggregates pass and others. I can't seem to find >> a combination of passes or transformations to get rid of them. Has >> anyone

Everyone, There is non-determinism in LLVM codegen in the following scenarios: 1. Between back-to-back runs of the same LLVM toolchain 2. Between Release vs Release+Asserts toolchains 3. Between Linux vs Windows toolchains The main reasons for the non-determinism in codegen are: 1. Iteration of unordered containers (like SmallPtrSet, DenseMap, etc) where the iteration order is undefined 2.

Hi! By only two cases I mean , that in exiting block when computing the condition related to PHI node I can expect only icmp on one of incoming values or on phi node itself... I tried to come up with some more complex examples but I always receive only these two cases, that is why I am asking. This problem still relates to the problem of all induction, cumulative and so on variables in loop. SCEV

Hi: I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. 1. MachineDominatorTree *domintree = new MachineDominatorTree(); domintree->runOnMachineFunction(mf); 2. Then travel mf one by one. When domintree->dominates(next,current) is true, there is a backedge from current node to next node. move this backedge form CFG. But I find A LOOP in

I guess not since Value is a superclass of Instruction. On Mon, Feb 6, 2012 at 10:36 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Ryan Taylor <ryta1203 at gmail.com> > Date: Mon, Feb 6, 2012 at 10:36 AM > Subject: Re: [LLVMdev] Updating PHI for Instruction Domination? > To: Eric Christopher <echristo at