similar to: SCEV cannot compute the trip count of Simple loop

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

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 Deepali, SCEV reports the backedge taken count as "((-1 * (sext i32 (3 + %x) to i64))<nsw> + ((sext i32 (3 + %x) to i64) smax (sext i32 (6 + %x) to i64)))", so symbolically it does have an answer. Ideally SCEV should be able to exploit <nsw> on (3 + %x) and (6 + %x) to fold the expression above to "3", but due to some systemic issues SCEV can't exploit

On 21 October 2013 17:29, Arnold Schwaighofer <aschwaighofer at apple.com>wrote: > I don’t think that recognizing this as a reduction is going to get you > far. A reduction is beneficial if the value reduced is only truly needed > outside of a loop. > This is not the case here (we are storing/loading from the pointer). > Hi Arnold, Nadav, Let me resurrect this discussion a

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

It's not clear what is actually wrong from your original message, I think you need to give some more information as to what you are doing: Example source, what target GPU, compiler error messages or other evidence of "it's wrong" (llvm IR, disassembly, etc) ... -- Mats On 8 April 2016 at 09:55, Liu Xin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I built it

On 07/04/2013 01:39 PM, Stéphane Letz wrote: > Hi, > > Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some

Hi, Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some informations that are needed by the vectorization passes to

> On Sep 16, 2016, at 1:56 PM, Kevin Choi via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > int mat[9][9][9]; > > for (p = (x+1) ; p < (x+3) ;p++) > > mat[x][p-1][i] = mat[x][p-1][i] + 5; > > } > The trip count of 2 should be valid for x in [0,6]. It is not clear to me why the trip count of 2 isn’t *always* valid. > If SCEV doesn't catch

It seems there is no -enable-iv-rewrite now in llvm3.2, and it suggest -enable-load-pre, but it still does not work. So, how to active the transform? -- View this message in context: http://llvm.1065342.n5.nabble.com/indvars-issues-tp4646p58587.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

I just subscribed this group. This is my first time to post a question (not sure if this is a right place for discussion) after I have a brief look at LLVM OPT (dev trunk). I would expect loop simplification and induction variable canonicalization pass (IndVarSimplify pass) should be able to convert the following loops into a simple canonical form, i.e., there is a canonical induction variable

Hello, Everyone. I have a question about llvm's "Combine redundant instructions(instcombine)" pass. I have tested instcombine pass by writing the following three test cases. But, CASE3 is not optimized as I expected. Is this behavior expected? The version of llvm is: clang version 5.0.1 (tags/RELEASE_501/final 325232) Option of clang command is: clang -O1 a.c -S -emit-llvm

Renato, can you post a hand-created vectorized IR of how a reduction would work on your example? I don’t think that recognizing this as a reduction is going to get you far. A reduction is beneficial if the value reduced is only truly needed outside of a loop. This is not the case here (we are storing/loading from the pointer). Your example is something like WRITEPTR = phi i8* [ outsideval,

Sorry, I could not the the loop trip count with getTripCount(). I used a simple program as a test case: ------------------------------------------------------ #include <stdio.h> int getV(int i) { return i * 2; } int main() { int num = 10; int sum=0; int i; for (i=0; i<num; i++) { sum += getV(i); } return 0;

Hi All, I was looking into MachineCopyPropagationPass.ccp file in llvm, which in first look, looks likes to me doing only redundant copy elimination in same basic block. I am interested in any pass which is doing copy propogation across the basic block in a function. Let me know if any such pass exist ? Thanks, Deepali -------------- next part -------------- An HTML attachment was scrubbed...

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. Would someone be willing to take a look at the failures and figure out why we're getting worse output once this patch is applied? If I had to hazard a guess, I'd say that indvars is probably emitting code

Thanks a lot for your guys' help!!! I guess once I am able to get *V* (which probably is a pointer to a Value object), then, I can instrument some code at the IR level to dump V. As long as I maintain V at this pass stage, I should be able to dump the loop trip count. This is true, isn't it? Basically, what I am going to do is to add a function call before the loop body, such as: