similar to: [LLVMdev] Induction variables and partial unrolling

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

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

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

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

Hi, I want to use loop unrolling pass, however, I find that loop unrolling will introduces conditional branch at end of every "unrolled" part. For example, consider the following code *void foo( int n, int array_x[])* *{* * for (int i=0; i < n; i++)* * array_x[i] = i; * *}* Then I use this command "opt-3.5 try.bc -mem2reg -loops -loop-simplify -loop-rotate -lcssa

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

Hi, I was looking at trying to get loop induction variable at IR level. LLVM documentation mentioned indvars pass and getCanonicalInductionVariable() to get them, I tried running the indvars pass and then a custom pass which iterates through loops and uses the function to obtain variable for a simple loop program. But the API returns null. I also read in similar posts that the indvars pass is not

On 01/16/2012 01:19 PM, Pieter Custers wrote: > I am new to LLVM and I've a question about the optimization passes and > in particular about the loop transformation passes. I've setup the LLVM > tool-chain with Polly installed. > > The following example is causing problems with me: > http://llvm.org/docs/Passes.html#indvars > > The input is a .c file with the

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

Hi Xiangyang, The algorithm for loop unrolling was changed post-3.5 to do more what you'd expect. If you use 3.6 or 3.7 you'll likely get better results. Cheers, James On Thu, 20 Aug 2015 at 18:09 Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 08/20/2015 07:38 AM, Xiangyang Guo via llvm-dev wrote: > > Hi, > > I want to use loop unrolling

Chris Lattner wrote: > > int main() > > { > > int r(0); > > for (int i = 0; i < 100; ++i) > > r += i; > > ; > > return r; > > } > > When I compiled it, I got the following LLVM code: The code I get is somewhat different: int %main() { entry: %tmp.1.i = load bool* %Initialized.0__ ; <bool> [#uses=1] br

On Wed, Jan 15, 2014 at 5:30 PM, Nadav Rotem <nrotem at apple.com> wrote: > Was the vectorizer successful in unrolling the loop in quantum_sigma_x? I > wonder if 'size’ is typically high or low. No. The vectorizer stated that it wasn't going to bother with the loop because it wasn't profitable. Specifically: LV: Checking a loop in "quantum_sigma_x" LV: Found a

I am new to LLVM and I've a question about the optimization passes and in particular about the loop transformation passes. I've setup the LLVM tool-chain with Polly installed. The following example is causing problems with me: http://llvm.org/docs/Passes.html#indvars The input is a .c file with the following loops: # 01 Standard, N=100 for (i=0; i<N; i++) b[i] = a[i] + 5; # 02

There's been some recent noise on the mailing list about requiring -fno-rtti; http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html Could that be it? On Sat, Aug 22, 2015 at 12:21 AM, Xiangyang Guo via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, James and Philip, Thanks for your help. > > Based on your advice, I downloaded llvm-3.7. However, with this new

On Wed, 31 Mar 2004, Vladimir Prus wrote: > I've just downloaded the latest release of LLVM, and playing with the > following simple example: > > int main() > { > int r(0); > for (int i = 0; i < 100; ++i) > r += i; > ; > return r; > } When I compiled it, I got the following LLVM code: int %main() { entry: call void %__main( )

Hello Tobi, Thank you for the quick reply. I updated my complete build suite with your script (http://polly.grosser.es/polly.sh). The make-test fails with some errors, the rest went smoothly; -- Exit Code: 1 Command Output (stderr): -- LLVM ERROR: Could not resolve external global address: stdout -- ******************** Testing Time: 10.01s ******************** Failing Tests (3): Polly ::

Hi Steve, Do you primarily find this to help for nested loops? If so, that could be because LSR explicitly bails out of processing them: // Skip nested loops until we can model them better with formulae. if (!L->empty()) { DEBUG(dbgs() << "LSR skipping outer loop " << *L << "n"); return; } I don't know how much time you're

> Can you suggest a good way to use the loops and induction variable > passes to map loop exiting BasicBlocks to InductionVariables. That is, > can we use these tools to identify the loop condition. I can try. :) It looks like you're running into problems because we don't perform "Linear Function Test Replacement". This optimization would reduce the amount of code