search for: getscevatscop

hi all, i have SCEVAddRec {{(32 + @edge.8265),+,32}<Loop0>,+,4}<Loop1> where Loop0 and Loop1 are brothers (loops at the same level of the loopnest), and Loop0 have a computable backedge taken count. when i call getSCEVAtScope({{(32 + @edge.8265),+,32}<Loop0>,+,4}<Loop1> , Loop1), it just give me a {{(32 + @edge.8265),+,32}<Loop0>,+,4}<Loop1>, instead of {some_value, + ,4}<loop0>, where some_value is getSCEVAtScope({(32 + @edge.8265),+,32}<Loop0>, Loop1). because Loop0 have a comput...

On Jun 29, 2010, at 7:08 AM, ether zhhb wrote: > > why computeSCEVAtScope not try to get the operands in the current > scope like the function do with SCEVCommutativeExpr, like: > > if (const SCEVAddRecExpr *AddRec = dyn_cast<SCEVAddRecExpr>(V)) { > if (!L || !AddRec->getLoop()->contains(L)) { > ... > // Then, evaluate the AddRec. >

Hi, Is it valid to query ScalarEvolution::getSCEVAtScope with a Value which is an Instruction inside the provided Loop? If so, I believe there is a bug in computeSCEVAtScope. Specifically: 04716     // If the scope is outside the addrec's loop, evaluate it by using the 04717     // loop exit value of the addrec. 04718     if (!AddRec->getLoop()-...

Nevermind. I misread the documentation. On Sat, Apr 30, 2011 at 8:12 PM, Thomas Jablin <tjablin at gmail.com> wrote: > Hi, > > Is it valid to query ScalarEvolution::getSCEVAtScope with a Value > which is an Instruction inside the provided Loop? If so, I believe > there is a bug in computeSCEVAtScope. Specifically: > > 04716     // If the scope is outside the addrec's loop, evaluate it by using the > 04717     // loop exit value of the addrec. > 04718  ...

...t be composed of recurrences that have no dominance relationship between them. Michael tried explaining to me why there is this restriction about dominance, and I'm beginning to understand why such restriction may be necessary when evaluating or expanding SCEV expressions in outer scopes (eg. `getSCEVAtScope(nullptr)`) but I still don't understand why this restriction is imposed at construction. Shouldn't this restriction be asserted on when calling getSCEVAtScope instead of when creating AddRecs, given that simplification steps may remove identical terms involving non-dominating loops? We wo...

Hi, You may try function "getSCEVAtScope" of the ScalarEvolution analysis: /// getSCEVAtScope - Return a SCEV expression for the specified value /// at the specified scope in the program. The L value specifies a loop /// nest to evaluate the expression at, where null is the top-level or a /// specified loop is immediately inside o...

Hi, I wonder how many of you are familiar with scalar evolution pass. I met a problem regarding to the SCEVAddRecExpr. Say for the code: const int N = 100; int a[N]; for(int i=0;i<N;i++) a[i] = 0; For the access of a[i], the pass will transform this a[i] to a SCEVAddRecExpr <@a, +, sizeof(int)><BB_Name>, which means the access of the array `a' starts from the address `a' and

..., we need to fully understand why that assumption about dominance is there and the implications of removing it. It would be good if you could be more specific about your idea of nullptr or SCEV_unknown (eg which function would return those values and when), but returning nullptr from getAddExpr or getSCEVAtScope may be problematic since they currently return valid pointers all the time and changing that would be error prone and would increase code complexity. Returning SCEV_Unknown from getAddExpr would seem plausible except that it would not allow for expression simplifications where recurrences over non...

...hat have no dominance relationship between them. Michael tried explaining to me why there is this restriction about dominance, and I'm beginning to understand why such restriction may be necessary when evaluating or expanding SCEV expressions in outer scopes (eg. `getSCEVAtScope(nullptr)`) but I still don't understand why this restriction is imposed at construction. Shouldn't this restriction be asserted on when calling getSCEVAtScope instead of when creating AddRecs, given that simplification steps may remove identical terms involving non-...

...nce relationship between them. Michael tried explaining to me why there is this restriction about dominance, and I'm beginning to understand why such restriction may be necessary when evaluating or expanding SCEV expressions in outer scopes (eg. `getSCEVAtScope(nullptr)`) but I still don't understand why this restriction is imposed at construction. Shouldn't this restriction be asserted on when calling getSCEVAtScope instead of when creating AddRecs, given that simplification steps may remove identi...

I've been doing some digging in this area (scev, wrapping arithmetic), learning as much as I can, and have reached a point where I'm fairly confused about the semantics of nuw in scalar evolution expressions. Consider the following program: define void @foo(i32 %begin) { entry: br label %loop loop: %idx = phi i32 [ %begin, %entry ], [ %idx.dec, %loop ] %idx.dec = sub nuw i32

..., and then we get a complex expression (but nothing with PHIs, I guess). And hopefully nothing with GEPs. So it's probably safe in your case. >> As an alternative, you can find your GEP's underlying phi and grab the value from the preheader. SCEV will tell you the difference between getSCEVAtScope and the preheader's expression, hopefully in terms of a constant or value+constant, and you should be able to materialize an inbounds gep. If any of these steps fail to find a simple solution, you can easily bailout. I'm glossing over the issues, but it would be nice to have a utility like...

...ing with PHIs, I guess). > > And hopefully nothing with GEPs. So it's probably safe in your case. > > >> As an alternative, you can find your GEP's underlying phi and grab > >> the value from the preheader. SCEV will tell you the difference > >> between getSCEVAtScope and the preheader's expression, hopefully > >> in terms of a constant or value+constant, and you should be able > >> to materialize an inbounds gep. If any of these steps fail to find > >> a simple solution, you can easily bailout. I'm glossing over the > >...

Hi Hashim, Scalar evolution determines evolution of scalar in terms of expression chain driving it. Try dumping the detailed log using opt -analyze -scalar-evolution <.ll> -S , and look for LoopDispositions corresponding to different expression which shows variance characteristics of a particular expression w.r.t loop i.e. [computable/variant/invariant]. Thanks On Fri, Dec 1, 2017 at

Hi Preston, >>> As noted in the GEP FAQ, GEPs don't support variable-length arrays; >> >> that's not quite right. The problem is only with arrays of variable length >> arrays, and more generally with arrays where the element type has variable >> size (this occurs with Ada, which has all kinds of funky variable sized types, >> for example). > >

Hi, I am using Scalar Evolution to extract access expressions (for load and store instructions) in terms of the loop induction variables. I observe that the Scalar Evolution analysis is returning more expressions than I expect - including ones that are not defined in terms of the loop induction variable. For instance in the following code: for(unsigned long int bid = 0; bid < no_of_queries;

Duncan Sands wrote: >> As noted in the GEP FAQ, GEPs don't support variable-length arrays; > > that's not quite right. The problem is only with arrays of variable length > arrays, and more generally with arrays where the element type has variable > size (this occurs with Ada, which has all kinds of funky variable sized types, > for example). You're right, though