similar to: [LLVMdev] induction variable computation not preserving scev

On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote: > Hi, > > I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test failures. Indvars isn't restructuring the loop there, so it ideally shouldn't need to call forgetLoop(). Offhand, is it possible that the problem

On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote: > > On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote: > > > Hi, > > > > I tracked down a bug in indvars where we weren't updating SCEV properly. > The attached patch shows the fix to this bug with a testcase, but it also > causes five new test failures. > > Indvars isn't

On Jan 19, 2011, at 2:03 PM, Nick Lewycky wrote: > On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote: > > On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote: > > > Hi, > > > > I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test

On 20 January 2011 11:23, Dan Gohman <gohman at apple.com> wrote: > > On Jan 19, 2011, at 2:03 PM, Nick Lewycky wrote: > > > On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote: > > > > On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote: > > > > > Hi, > > > > > > I tracked down a bug in indvars where we weren't

Hi folks, I'm trying to analyse this piece of IR: for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %0 = shl nsw i64 %indvars.iv, 1 %arrayidx = getelementptr inbounds i32* %b, i64 %0 %1 = load i32* %arrayidx, align 4, !tbaa !1 %add = add nsw i32 %1, %I %arrayidx3 = getelementptr

I would like to nominate Sanjoy Das as code owner of Scalar Evolution and Induction Variable Simplification. Scalar Evolution has never had an official code owner, but does regularly need in depth review. Over the past year and a half, Sanjoy has made fantastic contributions to SCEV and has been responsive reviewing patches. He is clearly the authority at this point. Induction variable

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: "Andrew Trick via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, May 25, 2016 6:17:54 PM > Subject: [llvm-dev] SCEV/IndVars Code Owner Nomination > > I would like to nominate Sanjoy Das as code owner of Scalar Evolution > and Induction Variable

> On May 25, 2016, at 4:27 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Andrew Trick via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "llvm-dev" <llvm-dev at lists.llvm.org> >> Sent: Wednesday, May 25, 2016 6:17:54 PM >> Subject: [llvm-dev] SCEV/IndVars Code Owner

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

> On May 25, 2016, at 4:17 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I would like to nominate Sanjoy Das as code owner of Scalar Evolution and Induction Variable Simplification. > > Scalar Evolution has never had an official code owner, but does regularly need in depth review. Over the past year and a half, Sanjoy has made fantastic contributions

On 05/26/2016 02:23 AM, Mikhail Zolotukhin via llvm-dev wrote: > >> On May 25, 2016, at 4:27 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> ----- Original Message ----- >>> From: "Andrew Trick via llvm-dev" <llvm-dev at lists.llvm.org> >>> To: "llvm-dev" <llvm-dev at lists.llvm.org> >>>

Hi All, I am trying to unroll the below loop, but couldn't as SCEV returns TripCount as 0. void foo(int x) { int p, i = 1; int mat[6][6][6]; for (p = x+3 ; p<= x+6 ;p++) mat[x][p][i] = mat[x][p][i] + 5; } For a quick reference I have added the generated IR compiled with clang using -O3. Please let me know if this is an known issue in SCEV or I am missing something here ? ;

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

I have modified the example test case for UB error, still it didn’t unroll void foo(int x) { int p, i = 1; int mat[9][9][9]; for (p = (x+1) ; p < (x+3) ;p++) mat[x][p-1][i] = mat[x][p-1][i] + 5; } Regard, Deepali From: Kevin Choi [mailto:code.kchoi at gmail.com] Sent: Friday, September 16, 2016 1:20 PM To: Rai, Deepali Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] SCEV

On Wed, Sep 19, 2012 at 6:30 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 19, 2012, at 2:18 PM, Preston Briggs <preston.briggs at gmail.com> > wrote: > > On Tue, Sep 18, 2012 at 10:59 PM, Andrew Trick <atrick at apple.com> wrote: > >> >> On Sep 18, 2012, at 8:21 PM, Preston Briggs <preston.briggs at gmail.com> >> wrote:

Hi, I'm working on a slow-compile problem caused by SCEV (PR28830), and I need your suggestions on how to fix it. The loop below causes ScalarEvolution::getMulExpr to hang. int get(unsigned n) { unsigned i, j, mult = 1; for (i = 0; i < 1; i++) { for (j = 0; j < 30; j++) { mult *= n++; } } return mult; } the inner loop is completed unrolled

Andy, et al., If I start with C code like this: void foo(long k, int * restrict a, int * restrict b, int * restrict c) { if (k > 0) { for (int i = 0; i < 2047; i++) { a[i] = a[i + k] + b[i] * c[i]; } } } Clang -O3 will produce code like this: entry: %cmp = icmp sgt i64 %k, 0 br i1 %cmp, label %for.body.preheader, label %if.end for.body.preheader: br label

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, I found issues with INDVARS <-> LSR passes interactions after https://reviews.llvm.org/rL346397. There were two main changes in this commit: 1. Previously we were propagating SCEV add expressions even if DefInst of exit value has hard uses inside the loop. After rL346397 we forbid propagation of SCEV add expressions if DefInst of exit value has hard use inside the loop. 2. Previously