similar to: [LLVMdev] [RFC] Invariants in LLVM

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu> > Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Andrew Trick" <atrick at apple.com>, "Richard Smith" > <richard at

On 07/17/2014 01:51 PM, Chandler Carruth wrote: > > > 2. Would adding a canonicalization of if(c) { unreachable } to > llvm.invariant(c) would be worthwhile? > > > There was a long and painful attempt to implement invariants based on > the branch-to-unreachable pattern. It didn't work. I don't expect > these patterns to show up often organically and to

On Thu, Jul 17, 2014 at 5:31 PM, Philip Reames <listmail at philipreames.com> wrote: > 3. An "llvm.invariant" has zero code generation cost. Given that, a lot > of pattern matching and profitability heuristics will need adjusted to > ignore them. > FWIW, this has been the fundamental point of contention in the entire design. I've discussed this several times with

Hi all! I'm new here, and would like to implement my own Loop Invariant Detection adding some more information on Quasi-Invariants. First, is there anything about Quasi-Invariants detection in LLVM I would missed? I've seen LICM using LoopInfo::isLoopInvariant for finding invariants. It seems that this method considers a Value invariant if: - it's an Instruction not presents in the

On Sep 7, 2013, at 7:41 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> 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

----- Original Message ----- > > > > On Sep 7, 2013, at 7:41 AM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > > 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

Ty Eli for your answer. On Tue, Jan 17, 2017 at 8:11 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/17/2017 7:12 AM, Thomas RUBIANO via llvm-dev wrote: > >> Hi all! >> >> I'm new here, and would like to implement my own Loop Invariant Detection >> adding some more information on Quasi-Invariants. >> >> First, is there anything

----- Original Message ----- > > > > On Aug 19, 2013, at 8:06 PM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > ----- Original Message ----- > > > > On Feb 22, 2013, at 6:28 AM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > ----- Original Message ----- > > > From: "Andrew Trick" < atrick at

On Wed, Jan 18, 2017 at 8:05 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/18/2017 2:56 AM, Thomas RUBIANO wrote: > > Ty Eli for your answer. > > On Tue, Jan 17, 2017 at 8:11 PM, Friedman, Eli <efriedma at codeaurora.org> > wrote: > >> On 1/17/2017 7:12 AM, Thomas RUBIANO via llvm-dev wrote: >> >>> Hi all! >>>

On Aug 19, 2013, at 8:06 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> >> On Feb 22, 2013, at 6:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> ----- Original Message ----- >>>> From: "Andrew Trick" <atrick at apple.com> >>>> To: "Hal Finkel" <hfinkel at anl.gov>

On Mon, Aug 19, 2013 at 10:06 PM, Andrew Trick <atrick at apple.com> wrote: > Metadata is a better approach because it doesn’t interfere with > optimizations that are free to ignore it. > But in practice, they aren't going to be free to ignore it. If you have metadata which encodes an invariant (in the most general sense, lifetime instrinsics currently encode an invariant,

----- Original Message ----- > > On Feb 22, 2013, at 6:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ----- 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>,

On 7/30/2013 11:44 PM, Chris Lattner wrote: > > The canonical form should be that loop invariants are hoisted. The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common" properties of a loop, such as header, preheader, latch branch, etc. > Optimizations should not depend on perfect

On Thu, Sep 12, 2013 at 4:52 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > If we only try to solve your immediate problem of > > builtin_assume_aligned, isn't that good enough for now? > > The thing that most concerns me about __builtin_assume_aligned and this > scheme is the control dependencies. In gcc, it is the return value of the > intrinsic that carries

On Feb 22, 2013, at 6:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- 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> >>

----- 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 Jul 31, 2013, at 6:53 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/30/2013 11:44 PM, Chris Lattner wrote: >> >> The canonical form should be that loop invariants are hoisted. > > The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common"

Hello again, In discussing my proposed patches for supporting alignment assumptions (for supporting __builtin_assume_aligned; see http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121126/157659.html), Chandler and I have started discussing an infrastructure for declaring invariants in the IR for use by the optimizer. The basic idea is to introduce a new intrinsic: void

On Oct 3, 2013, at 11:06 AM, Michele Scandale <michele.scandale at gmail.com> wrote: >> My very abstract suggestion for future improvements are: >> - At the SCEV level, logic to deduce that some recurrences cannot wrap given a set of loop facts derived from the IR and represented independent from the SCEV expressions themselves. > > I agree with this. I noticed that value

----- Original Message ----- > > > > > On Oct 3, 2013, at 11:06 AM, Michele Scandale < > michele.scandale at gmail.com > wrote: > > > > > My very abstract suggestion for future improvements are: > - At the SCEV level, logic to deduce that some recurrences cannot > wrap given a set of loop facts derived from the IR and represented >