similar to: [LLVMdev] Strong post-dominance in LLVM?

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

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

----- 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 Johannes, Sanjoy has given you great information already. On Sun, Apr 10, 2016 at 5:19 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Johannes Doerfert wrote: > > Is there any plan to use e.g., post-dominance information to > > propagate wrapping flags? > > None that I'm aware of. > > > If x +nsw y post-dominates the entry block > >

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

Many published analyses which build on post-dominance assume a canonical single-dominator-tree form induced by unifying all exits (and often adding a virtual edge from START to END). In contrast, it seems that the current LLVM post-dominator analysis only operates in a mode in which it generates a forest of post-dominator trees, with one rooted at each exit node. The problem this can cause is

On Aug 24, 2009, at 4:58 PM, Jonathan Ragan-Kelley wrote: > Many published analyses which build on post-dominance assume a > canonical single-dominator-tree form induced by unifying all exits > (and often adding a virtual edge from START to END). In contrast, it > seems that the current LLVM post-dominator analysis only operates in a > mode in which it generates a forest of

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

hi, I applied licm with basicaa on the following codes: int j = atoi(argc[1]); int lower[] = {10, 9, 8, 7, 6, 5, 4, 3, 2, 1}; int upper[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; for(i = lower[j]; a[i] < 100 && i < upper[j]; i ++); I notice that upper[j] is not hoisted out from the loop. Is this because j could be larger than 10? Thanks a lot! Best,

----- Original Message ----- > From: "Ashutosh Nema" <Ashutosh.Nema at amd.com> > To: "songlh" <songlh at cs.wisc.edu>, llvmdev at cs.uiuc.edu > Sent: Wednesday, February 11, 2015 3:20:27 AM > Subject: Re: [LLVMdev] question about licm > > Hi, > > LICM can only hoist instructions which dominates all loop exit > blocks. > In this case

Hi folks, For the past month I’ve been working on improving the DominatorTree and PostDominatorTree in LLVM. The RFC that explains the motivations and plans can be found here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114045.html . Here’s a short summary of what changed upstream since posting it: - We switched from the Simple Lengauer-Tarjan algorithm for computing dominators

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

On Mon, Jun 29, 2015 at 10:16 AM, Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> wrote: > Hi Anirudh, > > > > I hope these lecture slides about SSA and the dominance frontier will help > you with SSA and control flow analysis: > > > > http://www.seas.harvard.edu/courses/cs252/2011sp/slides/Lec04-SSA.pdf > > > > Unfortunately a use of

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

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 Piotr, On March 31, 2017 at 1:07:12 PM, Piotr Padlewski (piotr.padlewski at gmail.com) wrote: > [snip] > Do I understand it correctly, that it is legal to do the hoist because all > of the instructions above %vtable does not throw? Yes, I think you're right.  HeaderMayThrow is a conservative approximation, and the conservativeness is biting us here. > Are there any plans to

Here's a fun spin on this same topic (I can't file a bug at this moment since llvm.org is down). Consider: define i32 @x(i32* %x, i1* %y) { entry: br label %loop loop: %v = phi i32 [ 0 , %entry ], [ %v.inc, %exit.inner ], [ %v, %loop ] %c = load volatile i1, i1* %y br i1 %c, label %exit.inner, label %loop exit.inner: %c1 = load volatile i1, i1* %y %x.val = load i32, i32*

Thank you John. Actually the opt tool (from LLVM 3.2 version) can generate the needed graphs (with pass "-domfrontier"). But I just want to surely know is there some pass or builder which can be integrated somehow so it will be possible directly to generate CDG? -- View this message in context: http://llvm.1065342.n5.nabble.com/Control-Dependence-Graph-builder-tp56687p56689.html Sent

George Baah <georgebaah at gmail.com> writes: > Hi Guys, > > I saw in the API that DominanceFrontier has been deprecated. Is this > for real? > I have read the computational issues but shouldn't that be left to the > users of llvm? > My concern is I am writing a Control Dependence module that uses > Dominance-Frontier information. > Getting rid of Dominance