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

[Philip Reames]

On 11/20/2014 04:36 PM, Pete Cooper wrote:
> Hi Philip
>
> I added invariant.load in this commit: 
> http://llvm.org/viewvc/llvm-project?view=revision&revision=150257
>
> I’m not arguing against the changes you are proposing, but I just 
> wanted to give some clarification on the original intention of this 
> metadata, just incase that changes things.
>
> So in Objective-C, globals such as “*SELECTOR_REFERENCES*” are 
> initialized once, by the runtime.  They are then essentially constant. 
>  Unfortunately they aren’t compile time constants or we could just put 
> them in the appropriate section.
>
> This metadata was meant to solve exactly this situation, but never 
> considered for any others.  In particular, its undefined behavior in 
> Objective-C if anyone did chase pointers through the runtime and find 
> a way to modify one of these.  It’s therefore never expected that 
> you’ll see a store, call, or anything else, in any way modify one of 
> these.
Makes sense.  Just to be clear, did you intend for invariant.load to 
imply that the address of the selector variable was always 
dereferenceable?  The current *implementation* doesn't seem to assume 
that, but what's the history?
>
> TBH this metadata is probably the wrong thing for selector references, 
> or at least its name is.  What we really needed was some way to 
> describe 'externally initialized once before first use’ which implies 
> that its always invariant anyway.  That just never occurred to me at 
> the time of writing.
I'm trying to figure out how to support "initialized once (in visible 
IR) before first use".  The goal of this thread is really just to 
clarify what the current semantics are.  I think the current semantics 
actually implement both; I'm just trying to confirm this.


>
> Thanks,
> Pete
>> On Nov 20, 2014, at 4:25 PM, Philip Reames <listmail at philipreames.com 
>> <mailto:listmail at philipreames.com>> 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 <mailto:llvm-commits at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141120/31c8e1da/attachment.html>