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

Philip Reames listmail at philipreames.com
Thu Nov 20 16:25:31 PST 2014


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




More information about the llvm-commits mailing list