similar to: Status of llvm.invariant.{start|end}

> We at Azul have been using invariant.start for marking objects as immutable after a certain point. > Also, upstream changes to teach relevant optimizations about invariant.start and end were added > last year. > > With respect to store to load forwarding, this is handled in GVN. I think the test cases in test/Transforms/GVN/invariant.start.ll > handle what you’re looking for.

On Oct 31, 2017, at 3:50 PM, Anna Thomas via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On Oct 31, 2017, at 12:17 PM, Yichao Yu <yyc1992 at gmail.com<mailto:yyc1992 at gmail.com>> wrote: We at Azul have been using invariant.start for marking objects as immutable after a certain point. Also, upstream changes to teach relevant

> Just to clarify: If g can modify %a in some way, the front end needs to > identify it and avoid adding > invariant.start. OK cool, that's what I thought too. > > Once the invariant.start has been added by the front end,this is a perfectly > legal transform to do > based on the LLVM spec. > > In fact we should be implementing this in LLVM, patches welcome :)

On Mon, Apr 18, 2016 at 4:38 PM Xinliang David Li <davidxl at google.com> wrote: > >>>> Now, the original design only accounted for profile information >>>> *within* a function body, clearly it needs to be extended to support >>>> intraprocedural information. >>>> >>> >>> >>> Not sure what you mean. Profile data

On 09/28/2014 01:22 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Philip Reames" <listmail at philipreames.com> >> To: llvmdev at cs.uiuc.edu >> Cc: "Hal Finkel" <hfinkel at anl.gov>, nicholas at mxc.ca >> Sent: Wednesday, September 10, 2014 12:11:28 AM >> Subject: Optimization hints for "constant" loads

On Dec 8, 2011, at 10:03 PM, Nick Lewycky wrote: > Noalias returns, nocapture, SCC refinement, linkonce_odr and > available_externally were added with the goal of making devirtualization > in LLVM happen, but as orthogonal independent optimizations. I think > LLVM should continue with this design. If you want to implement a single > substantial optimization pass, I would suggest

On Mar 25, 2007, at 2:21 AM, Chris Lattner wrote: > On Sat, 24 Mar 2007, Christopher Lamb wrote: >> It seems to me that there is potential for doing some target >> independent loop >> invariant optimizations in the back end, but prior to instruction >> selection. > > I assume you mean after instruction selection? I assumed that to be target independent the

On Mon, Apr 18, 2016 at 3:45 PM Xinliang David Li <davidxl at google.com> wrote: > On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > >> On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov> wrote: >> >>> >>> >>> ------------------------------ >>> >>> *From:

Hi All, It seems to me that there is potential for doing some target independent loop invariant optimizations in the back end, but prior to instruction selection. For instance, I noticed that the loop invariant constant generated for a loop bounds check is still stuck inside the loop. Likewise constant address generated for globals accessed within a loop are generated on each iteration,

On Sat, 24 Mar 2007, Christopher Lamb wrote: > It seems to me that there is potential for doing some target independent loop > invariant optimizations in the back end, but prior to instruction selection. I assume you mean after instruction selection? > For instance, I noticed that the loop invariant constant generated for a loop > bounds check is still stuck inside the loop.

> I've never realy understood how the llvm.invariant intrinsics could be > put into practice. There is the problem that "end" can occur anywhere > as you suggested fixing with a flag. I was under this impression too, but after re-reading the language reference I'm not so sure -- it says about invariant.start: "This intrinsic indicates that until an

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Michele Scandale" <michele.scandale at gmail.com> > Cc: "llvmdev at cs.uiuc.edu List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, February 7, 2013 11:56:42 PM > Subject: Re: [LLVMdev] Rotated loop identification > > > On Feb 7, 2013, at 10:53 AM,

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu List" <llvmdev at cs.uiuc.edu>, "Michele Scandale" <michele.scandale at gmail.com> > Sent: Friday, February 8, 2013 1:52:55 PM > Subject: llvm.meta (was Rotated loop

On May 13, 2008, at 18:28, Dan Gohman wrote: > On May 12, 2008, at 6:49 PM, Talin wrote: > >> So the question is, what's the trade-off. In most languages that >> support exceptions, you tend to think of exceptions as expensive >> operations that should only be thrown if something truly >> "exceptional" happens. OTOH, the Java case is also made

Hi, I have the below test case. --snip-- struct st { int a; int b; }; int * ptr; int x,y; void bar(int *x); void foo() { struct st obj; bar(&obj.b); if(x) obj.a =x; else obj.a =y; for (int i=0; i<obj.a;i++) ptr[i]=i; } --snip-- LLVM IR produced at -O3 is shown below. ref: https://godbolt.org/z/WPlmfr --Snip-- %8 = getelementptr inbounds %struct.st,

Hi folks, I would like to ask for some help with handling invariant.group metadata for pointer comparison. Currently, we have a problem with devirtualization of this code: void compare() { A* a = new A; a->foo(); A* b = new(a) B; if (a == b) { b->foo(); } } Now because it is legal to replace b with an in the branch the vtable load will use old pointer operand

Am Freitag, den 16.05.2008, 06:54 -0700 schrieb Chris Lattner: > On May 13, 2008, at 4:09 PM, Gordon Henriksen wrote: > > > On May 13, 2008, at 18:28, Dan Gohman wrote: > > > > I wonder if it would be worthwhile to have a flag on loads to mark > > them as immutable. A flag from the source language stating "this load > > never aliases any subsequent

On Feb 7, 2013, at 10:58 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> As long as this is brainstorming time, I actually like the idea of an >> llvm.invariant intrinsic that the optimizers know to ignore. I like >> it for other purposes, but would happen to work for you as a >> temporary workaround. It could take one or two IR values (as >> metadata operands)

On Oct 12, 2010, at 5:31 AM, Kenneth Uildriks wrote: > On Tue, Oct 12, 2010 at 7:00 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> So does that mean that we're allowed to assume that, given an "old" >> pointer to that memory, the vtbl-ptr slot hasn't changed? Which >> allows us to devirtualize: >> >> Base* pT =

On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote: > On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote: >> A better way for a front-end to declare that vtbl-ptr-hacking is not >> expected and not supported is for it to emit llvm.invariant.start and >> llvm.invariant.end calls for it. > > Some of us were talking about this apropos your