search for: invariance

...limit the usefulness of the invariant attribute. I would expect invariant to indicate that loads reachable from the one marked invariant are guaranteed to read the same value, but that prior ones are not. This would allow updates to be made to the location of interest up to the point of declared invariance, but not after. > This has the benefit of covering the fact that no outside entity (i.e. the operating system) > changes the value, and that we can change it, but only to the same value it had before (if > we'll later be able to observe the difference). > Some questions: Do we a...

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

...suming it's otherwise known dereferenceable). Given this, why do we have both? Should we canonicalize one into the other? It would be very confusing if the two had different semantics. In either case, hoisting the load (without dropping metadata) is definitely legit. But conservatively, the invariance is still a path sensitive property. The load is invariant w.r.t. any store as long as control reaches a use-with-side-effects of the loaded value. Given: store %q m1 = load %p if <something> { m2 = load %p, !invariant.load } m = phi(m1, m2) We can safely convert to: m2 = load %p, !invari...

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:

...uses. The problem here is that > the optimizer could (in theory) introduce new uses of the pointer > after the object lifetime. This is the same problem that you yourself > have raised. I hoped we could sidestep the problem because it crops up > with any representation that attaches invariance to a pointer value. > If we have an answer for this, then we can easily debate other > representations like broadening !invariant.load metadata semantics and > introducing new intrinsics. I agree there is a general issue here. However, I don't actually think it's an issue of i...

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

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

...second to your problematic example? I'm missing the reasoning by which you got there. I agree that the example is problematic, I'm just not sure how it would arise. > > Either we need to make a convincing argument, or bail on most of the > tentative proposals for expressing invariance, and resort to > generating IR like this: > > %a = newArray() > %pLen = gep(%a, <length offset>) > %t = invariant.start(<size>, %pLen) > %len = load %pLen > > %o = foo() // may deallocate %a > invariant.end(%t, <size>, %pLen) > store %something >...

...t after the last use of the instance pointer. Then a few simple improvements to inlining & partial specialization will give you some interprocedural devirtualization. Anyway, you convinced me a few messages ago that invariant.end really should be left the way it is. Especially since assuming invariance hasn't ended when it has is unsafe... we *must* be able to match an invariance start to its corresponding invariance end in all cases.

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

2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov>: > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: > > > > 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

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

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!

On 01/28/2017 10:36 AM, Piotr Padlewski wrote: > > > 2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>>: > > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: >> >> >> 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk >> <mailto:richard at metafoo.co.uk>>: >>

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

...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 invariance. For example, when you inline, you would have to transform invariant loads to the scoped invariant thing. In NVPTX I am on a quest to use invariant loads for loads that must never change during the execution of a kernel. If the metadata signaled this more restricted scope, I guess I'd have t...

> On Mar 19, 2015, at 9:46 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > Thanks Adam for your reply. > > From: Adam Nemet [mailto:anemet at apple.com <mailto:anemet at apple.com>] > Sent: Friday, March 20, 2015 3:23 AM > To: Nema, Ashutosh > Cc: Hal Finkel; Philip Reames; llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu> > Subject:

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.