similar to: Late setting of SCEV NoWrap flags does bad with cache

Thanks for your insides Sanjoy! I don't really believe that option 2 may work just because even if we recalculate the range for this add recurrency, there are already its derivatives with cached ranges (the most obvious example is sext and expressions where this sext is involved). We can speculate about what is "simple enough" to not cache the ranges, but I believe that there is

Hi, I think these two patches are related to the topic: https://reviews.llvm.org/D41578 “[SCEV] Do not cache S -> V if S is not equivalent of V” * It’s committed. It can cause generation of redundant instructions. We’ve got regressions due to it. The biggest one is 7.31% regression in Spec2k6 401.bzip2 on Cortex-A57(AArch64). https://reviews.llvm.org/D42290 “[SCEV] Clear poison flags

On Thu, Jan 25, 2018 at 9:55 PM, Maxim Kazantsev <max.kazantsev at azul.com> wrote: > I don't really believe that option 2 may work just because even if we recalculate the range for this add recurrency, there are already its derivatives with cached ranges (the most obvious example is sext and expressions where this sext is involved). We can speculate about what is "simple

Hi Max, On Wed, Jan 24, 2018 at 10:03 PM, Maxim Kazantsev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I want to raise a discussion about reasonability of late setting of > nsw/nuw/nw flags to SCEV AddRecs through setNoWrapFlags method. A discussion > about this have already happened in August last year, there was a concern > about different no-wrap flags that come from

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

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

On Tue, Sep 18, 2012 at 10:59 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 18, 2012, at 8:21 PM, Preston Briggs <preston.briggs at gmail.com> > wrote: > > Given the following SCEV, > > *(sext i32 {2,+,1}<nw><%for.body> to i64)* > > > from the following C source, > > *void strong3(int *A, int *B, int n) {* > * for (int i =

Hi folks, I'm trying to analyse this piece of IR: for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %0 = shl nsw i64 %indvars.iv, 1 %arrayidx = getelementptr inbounds i32* %b, i64 %0 %1 = load i32* %arrayidx, align 4, !tbaa !1 %add = add nsw i32 %1, %I %arrayidx3 = getelementptr

On 8/8/2017 1:37 PM, Friedman, Eli wrote: > On 8/8/2017 10:22 AM, Geoff Berry via llvm-dev wrote: >> Hi all, >> >> I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of 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

On Wed, Sep 19, 2012 at 6:30 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 19, 2012, at 2:18 PM, Preston Briggs <preston.briggs at gmail.com> > wrote: > > On Tue, Sep 18, 2012 at 10:59 PM, Andrew Trick <atrick at apple.com> wrote: > >> >> On Sep 18, 2012, at 8:21 PM, Preston Briggs <preston.briggs at gmail.com> >> wrote:

On Sep 19, 2012, at 2:18 PM, Preston Briggs <preston.briggs at gmail.com> wrote: > On Tue, Sep 18, 2012 at 10:59 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 18, 2012, at 8:21 PM, Preston Briggs <preston.briggs at gmail.com> wrote: > >> Given the following SCEV, >> >> (sext i32 {2,+,1}<nw><%for.body> to i64) >>

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,

Given the following SCEV, *(sext i32 {2,+,1}<nw><%for.body> to i64)* from the following C source, *void strong3(int *A, int *B, int n) {* * for (int i = 0; i < n; i++) {* * A[i + 2] = i;* * ...* * }* *}* Since the No-Wrap flag is set on the addrec, can't I safely rewrite it as *{2,+,1}<nw><%for.body>* If I can, why isn't the SCEV package

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, I have a SCEV like this: {16,+,8}. Say that this came from a loop like: int64_t *p; for (int64_t i = 0; i < ...; ++i) p[i+2]... And assuming that I'm on a 64-bit machine. What I would like to do is normalize it like that, basically this: {2,+,1} i.e. map it to the index. Now, I tried to get the underlying element size of the pointer, then getUDivExpr(OriginalSCEV, ElementSize); But

On Nov 13, 2013, at 3:39 AM, Renato Golin <renato.golin at linaro.org> wrote: > Hi folks, > > I'm trying to analyse this piece of IR: > > for.body: ; preds = %for.body, %entry > %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] > %0 = shl nsw i64 %indvars.iv, 1 > %arrayidx = getelementptr inbounds

Hi, On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > Oh, I see... yes, we do stupid things involving mutating NoWrap flags after > a SCEV is created. (grep for setNoWrapFlags in ScalarEvolution.cpp.) That's really a compile time hack -- we defer some expensive tricks to prove nsw/nuw on an add recurrences to when we've been asked to

On Sep 18, 2012, at 8:21 PM, Preston Briggs <preston.briggs at gmail.com> wrote: > Given the following SCEV, > > (sext i32 {2,+,1}<nw><%for.body> to i64) > > from the following C source, > > void strong3(int *A, int *B, int n) { > for (int i = 0; i < n; i++) { > A[i + 2] = i; > ... > } > } > > Since the No-Wrap flag is

On 16 November 2013 06:56, Andrew Trick <atrick at apple.com> wrote: > - getMulExpr constructs a new AddRec with NSW: > > Flags = AddRec->getNoWrapFlags(clearFlags(Flags, SCEV::FlagNW)); > const SCEV *NewRec = getAddRecExpr(NewOps, AddRecLoop, Flags); > Hi Andrew, Thanks for looking at this. Clearing the flags here makes sense, but it's being too