similar to: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution

Hi Adam, Indvar widening can sometimes be harmful for architectures (e.g. NVPTX and AMDGPU) where wider integer operations are more expensive ( https://llvm.org/bugs/show_bug.cgi?id=21148). For this reason, we disabled indvar widening in NVPTX in http://reviews.llvm.org/D6196. Hope it helps. Jingyue On Mon, Jun 29, 2015 at 11:59 AM Adam Nemet <anemet at apple.com> wrote: > > >

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Jingyue Wu" <jingyue at google.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, June 30, 2015 8:16:13 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > > Hi Adam, > > Jingyue is right. We need to keep

Hi Sanjoy, thanks for your thoughts on this. On Sat, Jun 27, 2015 at 12:16 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > > First of all, going by the "poison causes UB only when observed", SCEV > does not do the right thing currently: [...] > > That seems like a bug? There's also bug 23527 for GEP. Sounds like there might be more such bugs. One

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, "Jingyue Wu" <jingyue at google.com> > Sent: Wednesday, July 1, 2015 2:27:59 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > >

Hi all, This is about a project I've been prototyping on-and-off for a while that has finally reached a point where I can claim it to be "potentially viable". I'd like to gather some input from the community before moving too far ahead. # The problem There is a representation issue within SCEV that prevents it from fully using information from nsw/nuw flags present in the

Hi Sanjoy, Any update on this? Are there plans to implement this proposal? Thanks, Pankaj -----Original Message----- Date: Fri, 23 Sep 2016 02:09:19 -0700 From: Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> To: llvm-dev <llvm-dev at lists.llvm.org>, Andrew Trick <atrick at apple.com>, Dan Gohman <dan433584 at gmail.com>, Hal Finkel <hfinkel at anl.gov>,

> On Aug 8, 2017, at 5:34 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Pankaj, > > IIRC there was pushback on this proposal so I did not proceed further. > Are you blocked on this? > > [+CC Andy, who I remember had some objections.] > > — Sanjoy Off the top of my head, my concern is that expression comparison is no longer constant time,

Hello, I was wondering under which circumstances ScalarEvolution will propagate the no wrap flags from binary operators. In particular I looked at non-loop carried code, e.g., as in the following function: int add(int x, int y) { return x + y; } for which clang uses an "add nsw" instruction but ScalarEvolution does not propagate this information. The -analyze output looks like this:

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

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 root causes seems to be that SCEV will return different nsw/nuw flags for the same Value, depending on what order the

[+Arnold] > On Jun 10, 2015, at 1:29 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > [+CC Andy] > >> Can anyone familiar with ScalarRevolution tell me whether this is an >> expected behavior or a bug? > > Assuming you're talking about 2*k, this is a bug. ScalarEvolution > should be able to prove that {0,+,4} is <nsw> and

On 10/03/2013 01:22 AM, Andrew Trick wrote: > > I’m not sure how to make sense of an NUW flag coming from a sub. > > NSW is just a misnomer for signed overflow. SCEV canonicalizes sub a,b to add a, (-b). Unfortunately, signed overflow is not the same thing for sub and add... > > sub nsw %a, %b != add nsw %a, (-1 * %b) > > sub nsw i32, -1, INT_MIN is true. > > add

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

Hey Sanjoy, Thanks for the quick repsonse. On 04/10, Sanjoy Das wrote: > [+CC Bjarke who wrote getNoWrapFlagsFromUB + related bits] Also thanks. > One fundamental reason why we cannot reason about NoWrap flags in SCEV > for arithmetic outside of loops is to avoid issues like this: > > if (cond) { > val[x +nsw y] = 42; > } else { > val[x + y] = 42; > } > >

On 23 Sep 2016, at 11:08, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Sep 23, 2016, at 2:09 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >> >> Hi all, >> >> This is about a project I've been prototyping on-and-off for a while >> that has finally reached a point where I can claim it to be >>

Ok. To go back to the original issue, would it be meaningful to add a SCEVUMax(0, BTC) on the final BTC computed by SCEV? So that it does not use "negative values"? On Wed, Aug 15, 2018 at 2:40 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > I'm not sure I understand the poison/undef/UB distinctions. >

I'm not sure I understand the poison/undef/UB distinctions. But on this example: define i32 @func(i1 zeroext %b, i32 %x, i32 %y) { > entry: > %adds = add nsw i32 %x, %y > %addu = add nuw i32 %x, %y > %cond = select i1 %b, i32 %adds, i32 %addu > ret i32 %cond > } It is important to not propagate the nsw/nuw between the two SCEV expressions (which unification would

Hi, We have recently encountered incorrect code generation issues and I think it is a SCEVExpander bug exposed by a recent patch to add nuw/nsw flags when generating code for SCEVMulExpr. The test case IR looks like this- %1 = load i16, i16* %arrayidx %2 = and i16 %1, -32768 The SCEV form of %2 is this- (-32768 * (%1 /u -32768))<nuw><nsw> It has both nsw/nuw flags. The signed

Is that why we do not deduce +<nsw> from "add nsw" either? Is that an intrinsic limitation of creating a context-invariant expressions from a Value* or is that a limitation of our implementation (our unification not considering the nsw flags)? On Wed, Aug 15, 2018 at 12:39 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 12:21 PM, Alexandre Isoard via

[+CC Andy] Hi Elena, I don't have any fundamental issues with teaching SCEV about floating point types, but given this will be a major change, I think a high level roadmap should be discussed on llvm-dev before we start reviewing and committing changes. Here are some issues that I think are worth discussing: - Core motivation: why do we even care about optimizing floating point