similar to: [LLVMdev] Adding Value to use_list of instruction

On Thu, Aug 2, 2012 at 2:52 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'd like to add a value to a use_list of a new instruction that I am > inserting, is this possible? > > I was looking at using Value::addUse(Use&), however, this doesn't take a > value, it takes a Use, so I need to pass the value as a use somehow? You normally shouldn't need to mess

I have a new block with new PHI instructions. I addIncoming for the PHIs but this apparently doesn't update the use list, which I am trying to use later on to update any instructions who are no longer dominated. On Thu, Aug 2, 2012 at 2:55 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Aug 2, 2012 at 2:52 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 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

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

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

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

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

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.

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

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

You're creating a new path that doesn't include L. For all values defined in L and used outside of L, you need to determine the new reaching def. That's specific to your transformation and can't be automated. Once you do that, creating the phi in F is natural. -Andy On Feb 6, 2012, at 11:51 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I guess not since Value is a

So I have a loop with two blocks, a header (which points to return and latch) and a latch (which points to return and header). I have inserted a few new blocks, called H and F. Header now points to H and latch. Latch now points to F. H points to F. F points to Header and return. The PHI Nodes have been updated in Header accordingly, now coming from the preheader and F (instead of latch). My

I understand that changing the starting element to “InsertedPHIs.being() + StartingPHISize” it will be finite but given that InsrtedPHIs is finite. I have a case where one element(same element is appened to InsertedPHIs) is added to InsertedPHIs every time fixupDefs is invoked. I traced the issue why this was happening. template <class RangeType> MemoryAccess

Not that I'm aware of. -eric On Feb 2, 2012, at 3:47 PM, Ryan Taylor wrote: > So essentially I'm adding a path inside of the loop. Is there a way to have llvm automatically create new IR and update the PHIs simply by adding a block like this and changing the DomTree? > > ---------- Forwarded message ---------- > From: Ryan Taylor <ryta1203 at gmail.com> > Date:

Conditional on the target supporting cmov? Though that's probably not optimal. On Wed, Feb 5, 2020, 7:47 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > Hi Ryan, > > On Mon, Feb 3, 2020 at 7:08 PM Ryan Taylor via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > SimplifyCFG FoldTwoEntryPhiNode looks to simplify all 2 entry phi nodes > in a block, if it

So essentially I'm adding a path inside of the loop. Is there a way to have llvm automatically create new IR and update the PHIs simply by adding a block like this and changing the DomTree? ---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Thu, Feb 2, 2012 at 12:08 PM Subject: Updating PHI for Instruction Domination? To: llvmdev at cs.uiuc.edu So

You can call addIncoming(). /// addIncoming - Add an incoming value to the end of the PHI list /// void addIncoming(Value *V, BasicBlock *BB) { assert(V && "PHI node got a null value!"); assert(BB && "PHI node got a null basic block!"); assert(getType() == V->getType() && "All operands to PHI node must be the same