similar to: Improving SCEV's behavior around IR level no-wrap

> 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,

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

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 >>

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

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

*** Summary I'd like to propose (and implement) functionality in LLVM to determine when a poison value from an instruction is guaranteed to produce undefined behavior. I want to use that to improve handling of nsw, inbounds etc. flags in scalar evolution and LSR. I imagine that there would be other uses for it. I'd like feedback on this idea before I proceed with it. *** Details Poison

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 Andy, Andrew Trick wrote: >> On Sep 23, 2016, at 7:50 AM, Christof Douma <Christof.Douma at arm.com <mailto:Christof.Douma at arm.com>> wrote: >> >> I can’t help to ask. Why not define a wrapping nsw instruction as UB, instead of “delayed UB” aka poison? I believe we >> have the notion of poison solely to ease the movement of instructions. In my example

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

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

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

[+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

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

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

> 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 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

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

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