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

[Philip Reames]

After offline discussion w/Sanjoy, I'm revising my proposed wording to 
the following:
"The optional ``!invariant.load`` metadata must reference a single
metadata name ``<index>`` corresponding to a metadata node with no
entries. The existence of the ``!invariant.load`` metadata on the
instruction tells the optimizer and code generator that the address
operand to this load points to memory which can be assumed unchanged
by any store. Being invariant does not
imply that a location is dereferenceable, but it does imply that once
the location is known dereferenceable it's value is henceforth unchanging. "

These aren't intended to be semantic changes, but they remove some 
confusion in the wording.  (There's no need to explicitly mention 
aliasing or dynamic paths.)


On 11/20/2014 04:25 PM, Philip Reames wrote:
>
> On 11/20/2014 04:14 PM, Sanjoy Das wrote:
>>> To clarify that the invariant nature of a given pointer does not 
>>> preclude the modification of that location through a pointer which 
>>> is unrelated to the load operand. In particular, initializing a 
>>> location and then passing a pointer through an opaque intrinsic 
>>> which produces a new unrelated pointer, should behave as expected 
>>> provided that the intrinsic is memory dependent on the initializing 
>>> store.
>> Does this mean you cannot common loads for escaped memory over 
>> calls?  The call could have modified the pointed-to location using 
>> another pointer.
> No, it does not.  The optimizer is free to assume that the location as 
> seen through *this* pointer is invariant.  Whether another copy of the 
> pointer escaped is irrelevant to that assumption.  The call may 
> contain a "potentially aliasing store" in my proposed wording.
>
> The scheme I was trying to describe in my clarification (not LangRef 
> wording!) was this:
> %p = ...
> store i32 5, i32* %p
> %p2 = call i32* @opaque_call(i32* %p)
> %v = load i32* %p2, !invariant !{}
>
> The fact that %p and %p2 might happen to be the same location is 
> irrelevant to the fact that the location as seen by %p2 is invariant 
> and the location as seen by %p is not.  In this case, I would expect 
> the load from %p2 to see the value stored to %p, but that's only 
> because the optimizer can't provide that %p == %p2. If it could, then 
> the value of the load is unclear.  (5, or whatever value that field 
> had before...)
>
>>
>> http://reviews.llvm.org/D6346
>>
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits