search for: tripcounts

Dear guys, I am having problems to obtain good information from the LoopInfo. I am always getting a trip count of 0, even though I am clearly passing a loop with a constant bound. I am using this pass below: void testLoopInfo(const Function& F) const { const LoopInfo *LI = &getAnalysis<LoopInfo>(); Function::const_iterator BB = F.begin(), E = F.end(); for (; BB !=

Dear All, I am glad to be part of GSoC 2016 with LLVM organization. I am a first year PhD student at IIT Hyderabad, India and my research area is compiler optimizations using polyhedral model. My GSoC 2016 project is to implement Polly as an Analysis pass in LLVM [1]. We have a discussion on Polly-dev mailing list [2] on taking a better approach to implement this project. Based upon this

hi, In "LoopUnrollPass.cpp", when trying to reduce unroll count to meet the unroll threshold requirement in line 200 and line 206, variable "CurrentThreshold" is used in the computation, instead of the variable "Threshold", which is defined by: // Determine the current unrolling threshold. While this is normally set // from UnrollThreshold, it is overridden to

Hi, This is a proposal about implementing an analysis that calculates loop cost based on cache data. The primary motivation for implementing this is to write profitability measures for cache related optimizations like interchange, fusion, fission, pre-fetching and others. I have implemented a prototypical version at http://reviews.llvm.org/D21124. The patch basically creates groups of references

Hi, Ivan: Sorry for deviating the topic a bit. As I told you before I'm a LLVM newbie, I cannot give you conclusive answer if the proposed interface is ok or not. My personal opinion on these two interface is summarized bellow: - hasZeroCostLoop() pro: it is clearly state the HW support. con: Having zero cost loop doesn't imply the benefit HW loop could achieve.

...opt -indvars | opt -analyze -scalar-evolution" which led me to add the forgetLoop here. Ah, I tried the testcase, saw the crash, and assumed that was the bug you were aiming to fix. The forgetLoop() call shouldn't be necessary for correctness. But I do see how ScalarEvolution's cached tripcounts are sub-optimal in this case, because they retain the type of the loop's original induction variable, rather than the type that indvars has chosen for the new induction variable. So forgetLoop() makes sense there. Dan

On Wed, Jun 8, 2016 at 10:20 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ------------------------------ > > *From: *"Vikram TV via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"DEV" <llvm-dev at lists.llvm.org> > *Sent: *Wednesday, June 8, 2016 2:58:17 AM > *Subject: *[llvm-dev] [Proposal][RFC] Cache aware Loop Cost Analysis >

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

Hi Shuxin, On 23/11/2012 00:17, Shuxin Yang wrote: > Hi, Gang: > > I don't want to discuss Open64 internal in LLVM mailing list. Let us > only focus on the design per se. > As your this mail and your previous mail combined give me a impression > that : > > The only reason you introduce the specific operator for HW loop in > Scalar Opt simply because >

hi, The loopinfo pass failed to recognize the Tripcount of a simple program constructed by me, can you help me to figure out why this happened? Thanks. The C program and corresponding .ll files are shown below. I used llvm1.7 to develop my own pass, and want to use the loop information. -Wei Test.c: #include "stdio.h" #define N 40 void func1() { int a[N]; int i,j; for

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

Hi devs, Recently I came across an interesting testcase that LLVM failed to optimize well. The test does some image processing, and as a part of it, it traverses all the pixels and computes some value basing on the adjacent pixels. So, the hot part looks like this: for(y = 0..height) { for (x = 0..width) { val = 0 for (j = 0..5) { for (i = 0..5) { val += img[x+i,y+j] *

Hi, Gang: I don't want to discuss Open64 internal in LLVM mailing list. Let us only focus on the design per se. As your this mail and your previous mail combined give me a impression that : The only reason you introduce the specific operator for HW loop in Scalar Opt simply because you have hard time in figure out the trip count in CodeGen. This might be true for Open64's

Hi, I am trying to get a small loop to *not vectorize* for cases where it doesn't make sense. For instance, this loop: void foo(int a[4][8], int n) { int b[4][8]; for(int i = 0; i < 4; i++) { for(int j = 0; j < n; j++) { a[i][j] = b[i][j]; } } } * Has maximum of 8ints copy. LLVM tries to use Memcpy for the inner loop. It is not helpful to perform

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

I did run the indvars pass, but it seemed that it didn't work. -Wei ----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, June 15, 2006 3:35 PM Subject: Re: [LLVMdev] problem with loopinfo > On Thu, 15 Jun 2006, Wei Jiang wrote: >> hi, >> The

On Thu, 15 Jun 2006, Wei Jiang wrote: > hi, > The loopinfo pass failed to recognize the Tripcount of a simple program constructed by me, can you help me to figure out why this happened? Thanks. > The C program and corresponding .ll files are shown below. I used llvm1.7 to develop my own pass, and want to use the loop information. What passes are you running before your pass? trip

On Thu, Jun 23, 2016 at 9:54 AM, Adam Nemet <anemet at apple.com> wrote: > > On Jun 9, 2016, at 9:21 AM, Vikram TV via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Wed, Jun 8, 2016 at 10:20 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> ------------------------------ >> >> *From: *"Vikram TV via

...alues of the variables within the loop can't have been changed by this? I expected to find such a property based on my understanding of indvars, but when I looked through the code I couldn't convince myself of it. Can you make such an argument? But I do see how ScalarEvolution's cached tripcounts > are sub-optimal in this case, because they retain the type of the loop's > original induction variable, rather than the type that indvars has > chosen for the new induction variable. So forgetLoop() makes sense > there. > That's what I expected, and what I see in the testc...

Hello Matthijs, On May 9, 2008, at 3:47 AM, Matthijs Kooijman wrote: > Hi All, > > the attached patch performs the splitting in the proposed manner. > before applying the patch, please execute > svn cp lib/Transforms/Scalar/LoopUnroll.cpp lib/Transforms/Utils/ > UnrollLoop.cpp > to make the patch apply and preserve proper history. > > Transforms/Utils/UnrollLoop.cpp