Displaying 20 results from an estimated 1775 matches for "invari".
Did you mean:
invar
2016 Aug 25
7
invariant.load metadata semantics
> 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...
2014 Jul 17
5
[LLVMdev] [RFC] Invariants in LLVM
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...
2017 Jan 25
4
RFC: Emitting empty invariant group for vtable loads
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...
2014 Dec 02
2
[LLVMdev] TBAA vs !invariant.load metadata semantics
...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...
2014 Oct 21
3
[LLVMdev] Optimization hints for "constant" loads
...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...
2017 Jan 20
4
RFC: Emitting empty invariant group for vtable loads
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...
2014 Dec 01
2
[LLVMdev] Optimization hints for "constant" loads
...>
>>>> 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...
2014 Jul 18
2
[LLVMdev] [RFC] Invariants in LLVM
...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 Jan 26
2
[cfe-dev] RFC: Emitting empty invariant group for vtable loads
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...
2014 Dec 01
2
[LLVMdev] Optimization hints for "constant" loads
...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...
2010 Oct 13
4
[LLVMdev] Missed devirtualization opportunities
...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
>&...
2014 Oct 21
2
[LLVMdev] Optimization hints for "constant" loads
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:/...
2017 Jan 28
2
[cfe-dev] RFC: Emitting empty invariant group for vtable loads
...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...
2015 Mar 24
3
[LLVMdev] RFC: Loop versioning for LICM
> 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...
2018 Mar 19
4
RFC: Devirtualization v2
...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...
2017 Jan 31
0
[cfe-dev] RFC: Emitting empty invariant group for vtable loads
...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...
2010 Sep 17
2
Constant vs Nonstop vs Invariant TSC question
...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...
2016 Aug 29
2
invariant.load metadata semantics
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...
2015 Mar 20
2
[LLVMdev] RFC: Loop versioning for LICM
...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...
2015 Jul 31
0
[LLVMdev] Clang devirtualization proposal
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...