similar to: [LLVMdev] using a SCEV

Hi Fellows, The goal is to find the induction variable for a loop, where the induction variable increments with the multiplication, division or shift operations, like this one: sz = 8; do { ... ... sz = sz / 2; } while (sz) Is SCEV capable of detecting the induction variable 'sz' in this case? The code snippet I am using to solve the problem is for each basic-block in a

The SCEV framework sorts operands of commutative SCEVs by their getSCEVType() value, and then does an ad-hoc sort to group repeated operands, but it does not do a full sort. In some test cases I'm looking at right now, this causes it to miss opportunities to reuse SCEV objects, as in cases like this: ( %i + %r54 + %r59) ( %r54 + %r59 + %i) As a result, passes like LoopStrengthReduce

On Fri, Apr 20, 2007 at 03:16:03PM -0700, Chris Lattner wrote: > > The obvious solution would be to sort the values. Many SCEV types could > > be ordered in reasonable ways, though for SCEVUnknown it would require > > an ordering for Value objects, and I don't really want this to get > > complicated. I'm considering just using getValueID() as a primary sort >

Hello to everybody, I'm working on some improvements on trip count computation with ScalarEvolution analysis. Considering the following test ;----------------------------------------------------------------------------; define void @foo(i32 %a, i32 %b, i32 %s) #0 { entry: %cmp = icmp sgt i32 %s, 0 %cmp15 = icmp sgt i32 %a, %b %or.cond = and i1 %cmp, %cmp15 br i1 %or.cond, label

On Oct 1, 2013, at 6:45 AM, Michele Scandale <michele.scandale at gmail.com> wrote: > Hello to everybody, > > I'm working on some improvements on trip count computation with ScalarEvolution > analysis. > Considering the following test > > ;----------------------------------------------------------------------------; > define void @foo(i32 %a, i32 %b, i32 %s) #0

Hi Nick, Thanks for looking into it. I have tried that as well but it didn't worked. "AddExpr->getOperand(0))" node is: " (4 * (sext i32 {2,+,2}<%for.body4> to i64))<nsw>" When I cast this to "SCEVAddRecExpr" it returns NULL. Regards, Ashutosh -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Thursday, March 19,

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 11/12/2011 12:11 AM, Hal Finkel wrote: > On Fri, 2011-11-11 at 23:55 +0100, Tobias Grosser wrote: >> On 11/11/2011 11:36 PM, Hal Finkel wrote: >>> On Thu, 2011-11-10 at 23:07 +0100, Tobias Grosser wrote: >>>> On 11/08/2011 11:29 PM, Hal Finkel wrote: Talking about this I >>>> looked again into ScalarEvolution. >>>> >>>> To

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 Fri, 20 Apr 2007, Dan Gohman wrote: > The SCEV framework sorts operands of commutative SCEVs by their > getSCEVType() value, and then does an ad-hoc sort to group repeated > operands, but it does not do a full sort. In some test cases I'm > looking at right now, this causes it to miss opportunities to reuse > SCEV objects, as in cases like this: > > ( %i + %r54 +

On Feb 24, 2012, at 9:53 AM, David A. Greene wrote: > Dan Gohman <gohman at apple.com> writes: > >>> These enhancements are critical for us because of the way our frontends >>> work (less than ideal but we have to deal with it), due to some language >>> quirks (casting in C, odd Fortran constructs, etc.) and because users >>> sometimes stretch the

Dan Gohman <gohman at apple.com> writes: >> These enhancements are critical for us because of the way our frontends >> work (less than ideal but we have to deal with it), due to some language >> quirks (casting in C, odd Fortran constructs, etc.) and because users >> sometimes stretch the boundaries of good taste :). >> >> Is this a reasonable approach?

Here's the current code (abstracted a bit) const Instruction *Src, const Instruction *Dst, // make sure they are loads and stores, then const Value *SrcPtr = getPointerOperand(Src); // hides a little casting, then Src->getPointerOperand const Value *DstPtr = getPointerOperand(Dst); // ditto // see how underlying objects alias, then const GEPOperator *SrcGEP =

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

Yes, I can get "SCEVAddRecExpr" from operands of "(sext i32 {2,+,2}<%for.body4> to i64)". So whenever SCEV cast to "SCEVAddRecExpr" fails, we have drill down for such patterns ? Is that the right way ? Regards, Ashutosh -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Thursday, March 19, 2015 1:02 PM To: Nema, Ashutosh Cc:

Hi, I'm trying to cast one of the SCEV node to "SCEVAddRecExpr". Every time cast return NULL, and I'm unable to do this. SCEV Node: ((4 * (sext i32 {2,+,2}<%for.body4> to i64))<nsw> + %var)<nsw> Casting: const SCEVAddRecExpr *AR = dyn_cast<SCEVAddRecExpr>(SCEVNode); 'var' is of type float pointer (float*). Without 'sext' it works, but

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

Hi Andy, Thanks very much for looking into the problem. In this particular test case, it seems most of the time is spent in the sorting, not the grouping. Later, I realized that it seems in this test case most of the expressions to be compared have different length. I tried the following change in compare() when the LHS and RHS's types are the same:

On 11/14/2011 01:24 AM, Marcello Maggioni wrote: > Hi Tobias. > > I worked on enabling Polly accepting non affine memory accesses and I > produced a patch. Great. > I saw that there were a lot of updates in Polly recently, so I had to > redo a lot of the work I did and that slowed me quite a bit. Ups, sorry! However, I believe without these changes detecting non-affine memory

Hello, I did a little experiment modifying LLVM to be able to use alias-analysis information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized