similar to: [LLVMdev] ScalarEvolution Patch

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

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

​Hi, Would you be able to kindly check and assist with the IndVarSimplify / SCEV problem I got in the latest LLVM, please? Sometimes IndVarSimplify may not eliminate narrow IV's when there actually exists such a possibility. This may affect other LLVM passes and result in inefficient code. The reproducing test 'indvar_test.cpp' is attached. The problem is with the second

Hi Sanjoy, Thank you for looking into this! Yes, your patch does fix my larger test case too. My algorithm gets double performance improvement with the patch, as the loop now has a smaller instruction set and succeeds to unroll w/o any extra #pragma's. I also ran the LLVM tests against the patch. There are 6 new failures: Analysis/LoopAccessAnalysis/number-of-memchecks.ll

Hello all, I wanted to get some feedback on this patch for ScalarEvolution. It addresses a performance problem I am seeing for simple benchmark. Starting with this C code: 01: signed char foo(void) 02: { 03: const int count = 8000; 04: signed char result = 0; 05: int j; 06: 07: for (j = 0; j < count; ++j) { 08: result += (result_t)(3); 09: } 10: 11: return result; 12: } I

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:

How do you generate a SCEVAddRecExpr from a SCEV? It tried dyn_casting and it seems like that the SCEV returned by getSCEV is not a SCEVAddRecExpr. Thanks On Fri, Sep 30, 2016 at 4:16 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/30/2016 12:16 PM, Charith Mendis via llvm-dev wrote: > >> >> Hi all, >> >> What is the best way to get the symbolic

We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal llvm::SCEVVisitor<SC, RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use of SCEVCouldNotCompute!"' failed. This happens in

Sorry typo in test case, Please ignore previous mail. Consider below case: for (j=1; j < itr; j++) { - - - - for (i=1; i < itr; i++) { { temp= var[i << 1]; - - - - - } } In the above example, we are unable to get "SCEVAddRecExpr" for "var[i << 1]" Its "SCEVAddRecExpr" is computable in *Outer Loop* I

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

David Greene wrote: > We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: > > llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal > llvm::SCEVVisitor<SC, > RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = > llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use of >

Hi, I'm working on a bug somewhere between SCEV and IndVarSimplify, which tacks an unwanted "nuw" onto an "add i32 %whatever, -1" (which actually almost certainly will overflow), leading ultimately to an infinite loop. A fuller description and test-case is at the end for anyone interested. The issue seems to be with ScalarEvolution's attempts to cache SCEV objects,

Hi Sanjoy, SCEV is behaving inconsistently when forming SCEV for this zext instruction in the attached test case- %conv5 = zext i32 %dec to i64 If we request a SCEV for the instruction, it returns- (zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64) This can be seen by invoking- $ opt -analyze -scalar-evolution inconsistent-scev-zext.ll But when computing

Thanks Sanjoy. > To be pedantic, "var[i<<1]" is not an add recurrence, but "&var[i << > 1]" is an add recurrence. I'll assume that's that you meant. Yes, I meant the same. > I think that is because in C, multiplication is nsw but left shift is > not and so "i << 1" can legitimately sign-overflow but i * 2 cannot >

On Friday 27 February 2009 00:50, Nick Lewycky wrote: > David Greene wrote: > > We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: > > > > llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal > > llvm::SCEVVisitor<SC, > > RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = > > llvm::SCEVExpander,

Hi, I'm working on a slow-compile problem caused by SCEV (PR28830), and I need your suggestions on how to fix it. The loop below causes ScalarEvolution::getMulExpr to hang. int get(unsigned n) { unsigned i, j, mult = 1; for (i = 0; i < 1; i++) { for (j = 0; j < 30; j++) { mult *= n++; } } return mult; } the inner loop is completed unrolled

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()->contains(L)) { 04719       // To

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

> 1. Callers are expected to not engage in speculation. ScalarEvolution > itself must only create expressions it knows hold in all cases. This is correct. There is some more relevant text in ScalarEvolution::isSCEVExprNeverPoison. And you're right, this is quite restrictive. > Long term, I think that it would be cleaner to rework this so that all of the SCEV's are immutable

Hi, +CC Max, Serguei This looks like a textbook case of why caching is hard. We first call getZeroExtendExpr on %dec, and this call does end up returning an add rec. However, in the process of simplifying the zext, it also calls into isLoopBackedgeGuardedByCond which in turn calls getZeroExtendExpr(%dec) again. However, this second (recursive) time, we don't simplify the zext and cache a