similar to: [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

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

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

It sounds like Transforms/Utils/SSAUpdater may be what you are looking for. A good example of how to use it -- one that sounds very similar to what you're doing -- can be found in Transforms/Scalar/LoopRotation.cpp On Wed, Mar 7, 2012 at 2:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I am splitting a one BB loop into two BB. > > Basically, the one loop BB has 3 incoming

Hi all, It looks like the induction variable simplification pass prefers doing a zero-extension to compute the wider trip count of loops when extending the IV. This can sometimes result in loss of information making ScalarEvolution's analysis conservative which can lead to missed performance opportunities. For example, consider this loopnest- int i, j; for(i=0; i< 40; i++) for(j=0;

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu > Sent: Thursday, July 16, 2015 1:06:03 AM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration

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

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu > Sent: Wednesday, July 15, 2015 7:34:54 PM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration variable > On Wed, Jul 15, 2015 at 12:55 PM Hyojin Sung

Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff

On 01/08/14 19:37, Reid Kleckner wrote: > What happens if you drop appending linkage? I think it will just work, > since you are already using a custom section, which will ensure that all > the data appears contiguously in memory. Thanks for the suggestion, but it still puts everything in a single .section statement. > Although, I do worry about what LLVM's alias analysis will

Hi Justin, the non-translatable IR with GPU code replaced by appropriate CUDA Driver > API calls. One of CUDA driver apis (cuLaunch) need a ptx asm string as its input. So if I want to provide a one-touch solution and don't introduce any changes to tools outside polly, I must prepare the ptx string before I can generate the correct non-translatable IR part. As your suggestion, It may

Hi Sanjoy, SCEV is behaving inconsistently when forming SCEV for this zext instruction in the attached test case- %conv5 = zext i32 %dec to i64 If we request a SCEV for the instruction, it returns- (zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64) This can be seen by invoking- $ opt -analyze -scalar-evolution inconsistent-scev-zext.ll But when computing

Hi, I've tracked the first problem (mentioned in my previous email, quoted below) down further, ending up in the handling of alloca in LoopRotation.cpp (from trunk): // If the instruction's operands are invariant and it doesn't read or write // memory, then it is safe to hoist. Doing this doesn't change the order of // execution in the preheader, but does

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Chandler Carruth" <chandlerc at google.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, July 16, 2015 1:58:02 AM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration variable > ----- Original Message ----- > >

2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>: > Hi, > > I've tracked the first problem (mentioned in my previous email, quoted > below) down further, ending up in the handling of alloca in > LoopRotation.cpp (from trunk): > >      // If the instruction's operands are invariant and it doesn't read > or write >      // memory, then it is

Over in pr26718, we ran across a case where input IR had one PHI within a basic block using the value of another PHI within the same basic block (without a backedge). There has been some disagreement as to whether this is valid IR. I believe it is not. The verifier currently accepts the following code without error: define void @f() { entry: br label %next next: %y = phi i32 [ 0,

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

Hello. I tried to get the trip count of a loop with Scalar evolution. I got inspired from http://stackoverflow.com/questions/13834364/how-to-get-loop-bounds-in-llvm . However the analysis described there doesn't work well for the second inner loop of thes function below (although if we declare Bcols a short it works well): void MatMul(int Arows, int Acols, int Brows, int

Hello, I am trying to use scalar evolution pass using following command; opt -analyze -mem2reg -indvars -loop-simplify -scalar-evolution < vec.bc when vec.bc is generated using newer version of LLVM i.e LLVM 6 and 7 i get following message in the end; Determining loop execution counts for: @main Loop %8: Unpredictable backedge-taken count. Loop %8: Unpredictable max backedge-taken count. Loop

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