[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