[PATCH] Clarify wording in the LangRef around !invariant.load

Andrew Trick atrick at apple.com
Mon Dec 1 11:20:01 PST 2014


> On Nov 24, 2014, at 2:04 PM, Nick Lewycky <nlewycky at google.com> wrote:
> 
> On 24 November 2014 at 13:01, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote:
> 
> > On Nov 24, 2014, at 2:06 AM, Nick Lewycky <nicholas at mxc.ca <mailto:nicholas at mxc.ca>> wrote:
> >
> > Andrew Trick wrote:
> > Comparing pointers of different objects should be considered illegal in LLVM, although I'm not sure where that's spelled out.
> >
> > "If the operands are pointer typed, the pointer values are compared as if they were integers." - http://llvm.org/docs/LangRef.html#id251 <http://llvm.org/docs/LangRef.html#id251>
> >
> > I disagree, and think llvm's current model is right. There used to be (still are?) some interesting rules on the inbounds gep instruction, but nothing that applies to pointers in general.
> >
> > We do end up with weird cases such as %ptr1 noalias %ptr2 while %ptr1 == %ptr2, but that only comes up because we recognize C functions and graciously handle C's aliasing rules for things like freed pointers and such. It's not actually part of llvm's execution semantics, nor does it need to be. It might hurt support for other languages if we did, and it would make %p eq %q different from ptrtoint %p eq ptrtoint %q, which in turn means you can't do transforms which that a given i64 in memory is always used as a pointer and replace the type loads and stores referring to it.
> >
> > Nick
> 
> Absolutely. My "comparing pointers" statement reads wrong out of context.
> 
> My apologies! I was catching up on days on email, and was only skimming instead of reading. That line really caught my eye.
> 
> The frontend can generate pointer comparisons wherever it is semantically valid to do so by language rules. Allowing LLVM passes to arbitrarily introduce comparisons on unrelated pointers, or similarly to introduce inttoptr, would limit what we can do with memory attributes. I'm primarily concerned with supporting non-C languages.
> 
> Concisely put, I agree with your assessment that we want memory intrinsics to behave more like dereferenceable does.
> 
> The immediate issue is the semantics of !invariant.
> 
> Given:
> 
> m1 = load %p, !invariant
> free(%p)
> %q = init()
> m2 = load %q
> foo(m2)
> 
> Can the optimizer do this?
> 
> m1 = load %p, !invariant
> free(%p)
> %q = init()
> if %p == %q
>   m2 = load %p
>   foo(m2)
> ...
> 
> Which, if we give !invariant semantics that I like, would allow this:
> 
> m1 = load %p, !invariant
> free(%p)
> %q = init()
> if %p == %q
>   foo(m1)
> ...
> 
> Even if we solve this problem, what would it mean for attributes that we associate with pointer values? For uniformity and expressiveness, we want to treat "invariant" as an attribute, the way we currently treat dereferenceable and nonnull.
> 
> So we have something like:
> 
> assume_invariant(%p)
> m1 = load %p
> free(%p)
> %q = init()
> m2 = load %p
> foo(m2)
> 
> Now semantics are broken the moment we introduce pointer comparison.
> 
> assume_invariant(%p)
> m1 = load %p
> free(%p)
> %q = init()
> if %p == %q
>   m2 = load %p
>   foo(m2)
> 
> It would be nice if the frontend could generally associate memory attributes with a particular object without needing to prove that the object has process lifetime. Do you think this is reasonable?
> 
> I haven't put any serious thought into trying to see where it could break, but it does sound like a reasonable model.
> 
> Sorry to jump in uninformed!

Thank you for jumping in. I don’t want to discourage that.

Your question was a good one. The model I was proposing is not fully defined. So far it is just wishful thinking given what I and others want to do in the frontend and optimizer. It all really comes down to whether we can define a model that imbues a pointer value with invariance without requiring llvm.invariant.end wherever the object's lifetime may end. I don’t think I’ve adequately argued that it’s safe.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141201/970aab85/attachment.html>


More information about the llvm-commits mailing list