search for: invari

> 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 invariant attribute. I would expect...

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

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 "identifi...

...BAA also contains a third field which indicates that "meaning pointsToConstantMemory should return true; see other useful AliasAnalysis methods <http://llvm.org/docs/AliasAnalysis.html#OtherItfs>". Looking at this a bit, it really seems like this flag has the exact same meaning as !invariant.load. > > pointsToConstantMemory returns a value for a Location. Since it is entirely legal to have two Locations which describe the same physical memory, it seems like you'd be back to the same semantics as !invariant.load. > > The only uncertainty here is that a Location...

...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 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 approach looks similar to...

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: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html My talk from LLVM Dev Meeting http://llvm.org/de...

...> >>>> 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 of an invariant region with no end. (Since the >>>> result doesn't escape, there can be no end hidden inside a function >>>> call.) This seems like a simple notion to e...

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

2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > On 25 January 2017 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. W...

...2/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 of an invariant region with no end. (Since the >> result doesn't escape, there can be no end hidden inside a function >> call.) This seems like a simple notion to exploit and is strict &g...

...king >>> them >>> local is to say that "I'm sure these callees won't modify that memory" >>> regardless of what functions actually get called, even indirectly. We >>> can't >>> know that they won't modify the vptr in advance, so invariant doesn't >>> work >>> here. Making it non-local just means that we would need to know the >>> static >>> call graph, which we don't because we haven't devirtualized yet so all >>> the >>> calls are indirect. >>> Nick >&...

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 approach looks similar to Ruby's "freeze" method: http:/...

...gt; > 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > >> On 25 January 2017 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 s...

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

...gned to solve the hole in the previous devirtualization model that could cause miscompilation. We believe that solving this is very important, especially with the mitigation of the recent Spectre vulnerability - retpolines.Introduction to previous devirtualizationIn the previous model we introduced invariant.group to LLVM as a way of saying “this load will produce the same value if given the same argument”, which was applied on loads from virtual pointer to communicate that virtual pointer (or in other words, dynamic type) does not change during the lifetime of an object. Because virtual pointer mi...

...k>>: >> >> On 25 January 2017 at 15:03, Hal Finkel via cfe-dev >> <cfe-dev at lists.llvm.org <mailto: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...

...cpuid_edx(0x80000007) & (1u<<8)) { set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability); set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability); } I am trying to determine the difference between the constant vs nonstop vs invariant TSCs in newer processors. I understand constant tsc means the rate of the counter won''t vary if the CPU freq changes and non-stop means that it even continues to count when the cpu is in a low power state. When I read Intel''s Designer''s vol3b, section 16.11.1 Invari...

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 a function and the last (possibly not invariant) load in the function? This seems like a very weak form of invari...

...current LAA, found few gaps for reusing it. > > i.e. > 928 void LoopAccessInfo::analyzeLoop(const ValueToValueMap &Strides) { > 1029 if (isUniform(Ptr)) { > 1030 emitAnalysis( > 1031 LoopAccessReport(ST) > 1032 << "write to a loop invariant address could not be vectorized"); > 1033 DEBUG(dbgs() << "LAA: We don't allow storing to uniform addresses\n"); > 1034 CanVecMem = false; > 1035 return; > 1036 } > > LAA is ignoring the cases where store is loop invariant, it se...

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. Quoting from the google doc: "If we don’t know definition of some function, we assume that it will not...