search for: invariants

> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev > Subject: Re: [llvm-dev] invariant.load metadata semantics > Alternatively, we might phrase this as: The optimizer may assume that all values loaded > from a location, where any of the loads are tagged with !invariant.load, are identical. This would seem to limit the usefulness of the

Hello everyone, I'm starting a new thread, as a follow-up to several older ones, on invariants in LLVM. Fundamentally, invariants are conditions that the optimizer is allowed to assume will be valid during the execution of the program. Many other compilers support a concept like this, MSVC's __assume, for example. GCC has a builtin called __builtin_assume_aligned which also neatly falls...

Hi Piotr, I think makes sense. Modulo bitcasts, the invariant is identified by a particular pointer SSA value. Given that you can't sensibly have two nonequivalent invariants associated with the same pointer SSA value simultaneously, there's no need to also identify the invariant with a metadata string as well. When we need a new "identifier" for the pointed-to value, we get one using invariant.group.barrier. -Hal On 01/24/2017 01:39 PM, Piotr Padl...

> On Dec 1, 2014, at 3:44 PM, Philip Reames <listmail at philipreames.com> wrote: > > (Spawning a separate subthread off the 'Optimization hints for "constant" loads' discussion for a related question. ) > > Looking at TBAA again, I was reminded that TBAA also contains a third field which indicates that "meaning pointsToConstantMemory should return

On 10/21/2014 01:44 PM, Andrew Trick wrote: >> On Oct 21, 2014, at 11:46 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >> >> Thank you for the explanation, I think I misunderstood your solution >> initially. Is it accurate to say: by making the definition of the >> source pointer of an !invariant load control (or data) dependent on >> some

Hi all, I would like to propose a new way clang would decorate vtable loads in order to handle devirtualization better. I've added *llvm-dev* also, because this can start a discussion about changing invariant.group to just invariant. PDF version of this RFC can be found here: https://drive.google.com/file/d/0B72TmzNsY6Z8ZmpOUnB5dDZfSFU/view?usp=sharing Background: Initial old design:

On 12/01/2014 02:42 PM, Andrew Trick wrote: > >> On Dec 1, 2014, at 2:21 PM, Philip Reames <listmail at philipreames.com >> <mailto:listmail at philipreames.com>> wrote: >> >> >> On 12/01/2014 11:14 AM, Andrew Trick wrote: >>> >>>> On Oct 21, 2014, at 4:03 PM, Philip Reames >>>> <listmail at philipreames.com

...Chandler Carruth" <chandlerc at gmail.com>, "Andrew Trick" <atrick at apple.com>, "Richard Smith" > <richard at metafoo.co.uk>, "Nick Lewycky" <nlewycky at google.com> > Sent: Thursday, July 17, 2014 4:31:10 PM > Subject: Re: [RFC] Invariants in LLVM > > > On 07/17/2014 01:39 PM, Hal Finkel wrote: > > Hello everyone, > > > > I'm starting a new thread, as a follow-up to several older ones, on > > invariants in LLVM. Fundamentally, invariants are conditions that > > the optimizer is allowed to...

...7 at 15:03, Hal Finkel via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi Piotr, >> >> I think makes sense. Modulo bitcasts, the invariant is identified by a >> particular pointer SSA value. Given that you can't sensibly have two >> nonequivalent invariants associated with the same pointer SSA value >> simultaneously, there's no need to also identify the invariant with a >> metadata string as well. When we need a new "identifier" for the pointed-to >> value, we get one using invariant.group.barrier. >> > > A...

On 12/01/2014 11:14 AM, Andrew Trick wrote: > >> On Oct 21, 2014, at 4:03 PM, Philip Reames <listmail at philipreames.com >> <mailto:listmail at philipreames.com>> wrote: >> >> Sanjoy made a good point. We don't actually need a new variant of >> "invariant.start". Simply using an invariant.start with no uses >> gives us a notion

On Wed, Oct 13, 2010 at 12:45 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Kenneth Uildriks wrote: >>> >>> You're right, I hadn't thought this through. The whole point of making >>> them >>> local is to say that "I'm sure these callees won't modify that memory" >>> regardless of what functions actually get called,

Thank you for the explanation, I think I misunderstood your solution initially. Is it accurate to say: by making the definition of the source pointer of an !invariant load control (or data) dependent on some initialization event, you can effectively separate the initialization event (where the location is not invariant) and the rest of the execution (where the location is invariant). This

...fe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> Hi Piotr, >>> >>> I think makes sense. Modulo bitcasts, the invariant is identified by a >>> particular pointer SSA value. Given that you can't sensibly have two >>> nonequivalent invariants associated with the same pointer SSA value >>> simultaneously, there's no need to also identify the invariant with a >>> metadata string as well. When we need a new "identifier" for the pointed-to >>> value, we get one using invariant.group.barrier. >>...

> On Mar 20, 2015, at 8:02 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > > Yes, this is what I was proposing above and here ;): > Thanks Adam it’s for confirming J NP :). > > > No, not hasLoopInvariantStore but hasAccessToLoopInvariantAddress. > Its only for invariant stores[not loads], Using ‘hasLoopInvariantStore’ (or a name with invariant store) makes more sense over ‘hasAccessToLoopInvariantAddress’. Right but it’s the address that’s invariant not the store so hasLoopInvariantStore is a mi...

Hi folks, here is a link to the proposal that we've been working on lately: https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBt vjWUod2SujZVEo/edit?usp=sharing But for the record, I also paste it here. Feedback will be really appreciated!

...lists.llvm.org>> wrote: >> >> Hi Piotr, >> >> I think makes sense. Modulo bitcasts, the invariant is >> identified by a particular pointer SSA value. Given that >> you can't sensibly have two nonequivalent invariants >> associated with the same pointer SSA value >> simultaneously, there's no need to also identify the >> invariant with a metadata string as well. When we need a >> new "identifier" for the pointed-to value, we ge...

>From /xen-unstable.hg/xen/arch/x86/cpu/intel.c if ((c->x86 == 0xf && c->x86_model >= 0x03) || (c->x86 == 0x6 && c->x86_model >= 0x0e)) set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); if (cpuid_edx(0x80000007) & (1u<<8)) { set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); set_bit(X86_FEATURE_NONSTOP_TSC,

Sanjoy, can you clarify this bit about JVM array lengths? Presumably the same pointer can point to two arrays of different lengths during a program's execution. Does this mean that you're relying on invariant.load having function scope? That is, correctness depends on the pointer not being reused for an array of a different length between the first invariant load of that array length in

...could for example distribute the loop. > Yes, I think that functionality exists, but the only blocker to it is the check mentioned in my previous mail. > > So, instead of returning & setting ‘CanVecMem’ for loop invariant store. > Can’t we maintain a separate variable i.e. hasLoopInvariantStore in LoopAccessInfo and set it accordingly. Yes, this is what I was proposing above and here ;): > We couldn’t vectorize thus the analysis should provide a new piece of information about the loop having accesses to loop-invariant addresses. > > Also we can provide a getter function...

Ok, replying anew now that I understand why reasoning about abstract locations for each object doesn't work. The general idea of describing a set of load and stores which belong to a particular invariant group seems reasonable. I've got some questions/comments on the specifics, but the overall direction seems entirely workable for the specific problem you're trying to solve.