similar to: PHI nodes and connected ICMp

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

Thank you for your answer! I tested your example, yes, perhaps I should preserve some kind of tree to parse this start and end expressions for induction variable... I was surprised, that SCEV cannot compute the tripcount here. I thought, that all linear and maybe expressions with multiplication are suitable for analysis. 2017-08-10 19:30 GMT+02:00 Sanjoy Das <sanjoy at google.com>: > Hi

This support was removed years ago from indvars. We don't need canonical induction variables any more as all analysis are done on SCEVs. The SCEV generator can transform them even without the need for explicit canonical induction variables. Best, Tobias On Wed, Aug 9, 2017, at 14:23, Anastasiya Ruzhanskaya via llvm-dev wrote: > The files of this strange pass are described here >

To continue this topic: sometimes SCEV's behavior is rather controversial : for loops with i changing as i \=2 for example, he can't figure what the type of expressions is, but surprisingly can determine max trip count. Shouldn't it be able to detect or not detect these parameters at the same time? 2017-08-11 15:56 GMT+02:00 Anastasiya Ruzhanskaya < anastasiya.ruzhanskaya at

Hi, On Sun, Aug 13, 2017 at 5:58 AM, Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > And still, aren't there any possibilities to find that phi node, that led > SCEV to compute max trip count? So there is no good answer to your question since in most cases SCEV does not directly look at PHI nodes (or expressions based off of the PHI node). It converts

Hello, I have this piece of code: int main() { int m = 0; // int i, j, k; // int N = f()%10; for (int l = 0; l < 1000; l+=4) printf("%d", l); I am sure, that llvm is capable to convert this into canonical induction variable, but even with O3 define i32 @main() #0 { br label %2 ; <label>:1 ; preds

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

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

Hi Gerolf, I think we have several (perhaps separable) issues here: 1. Do we have a canonical form for loops, preserved through the optimizer, that allows naturally-constructed loop nests to remain separable? 2. Do we forbid non-lowering transformations that turn vectorizable loops into non-vectorizable loops? 3. How do we detect cases where transformations cause a negative answer to either

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

I call this function and it returns only "i" in my example. Are there any ways to return "j" also? 2017-07-25 19:11 GMT+02:00 Michael Kruse <llvmdev at meinersbur.de>: > There is Loop::getCanonicalInductionVariable() > > You may need to run the "-indvars" (IndVarSimplify) pass before it > returns a value. I am not sure it normalizes the step size

Hi, Scalar evolution seems to be wrapping around the trip count in the following loop. void add (int *restrict a, int *restrict b, int *restrict c) { char i; for (i = 0; i < 255; i++) a[i] = b[i] + c[i]; } When I run scalar evolution on the bit code, I get a backedge-taken count which is obviously wrong. $> cat loop.ll ; Function Attrs: nounwind define void @add(i32* noalias

Hi Anastasiya, If it fits you use case, you can consider walking the loop header and calling getSCEV() on all of the PHI nodes in the header. This will give you a SCEV* which should be easier to analyze than manually inspecting PHI cycles. Thanks! -- Sanjoy On Tue, Jul 25, 2017 at 11:42 AM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 2017-07-25 19:32 GMT+02:00

Hello, I need to perform the analysis of loop induction variables. However, as I understood, directly it is possible to extract only a canonical induction variable which is only one. If I have multiple induction variables with the step not one, are there any methods to extract their phi node? int a[10]; int b[10]; for (int i = 0, j = 1; i < 10, j < 10; i++, j+=2) {

Hi Pankaj, On April 14, 2017 at 4:55:16 PM, Chawla, Pankaj (pankaj.chawla at intel.com) wrote: > I have attached the IR I got by compiling with -O2. This is just before we widen the IV. Thanks! > To get the backedge taken count info I ran indvars on it and then replaced zext with sext. > > I think regardless of where we decide to add this transformation in the pipeline, it should

----- Original Message ----- > > > > On Jun 24, 2013, at 4:24 PM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > > Indvars should ideally preserve NSW flags whenever possible. However, > we don't want to rely on SCEV to preserve them. SCEV expressions are > implicitly reassociated and uniqued in a flow-insensitive universe > independent of the

But even for a very simple loop: int test1 (int *x, int *y, int *z, int k) { int sum = 0; for (int i = 10; i < k; i++) { z[i] = x[i] / y[i]; } return sum; } The initial value of induction variable is not zero after compiling with -O3 -mcpu=power8 x.cpp -S -c -emit-llvm -fno-unroll-loops (see bottom of the email for IR) Also I can write somewhat more complicated loop where step

Sent from my iPhone... On Jun 25, 2013, at 8:14 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> >> >> >> On Jun 24, 2013, at 4:24 PM, Hal Finkel < hfinkel at anl.gov > wrote: >> >> >> >> >> Indvars should ideally preserve NSW flags whenever possible. However, >> we don't want to

Hi Sanjoy, I have attached the IR I got by compiling with -O2. This is just before we widen the IV. To get the backedge taken count info I ran indvars on it and then replaced zext with sext. I think regardless of where we decide to add this transformation in the pipeline, it should try to preserve as much information as it can. This means that we should generate sext for signed IVs and