[llvm-dev] invariant.load metadata semantics

[Geoff Berry via llvm-dev]

I believe the following is a reasonable attempt at boiling down this 
discussion.  It does allow stores of the same value.  It avoids the dead 
invariant.load issue Sanjoy brought up.  It does not allow final stores 
of a different value, the issue Hal most recently brought up in this thread:

     If a load instruction tagged with the ``!invariant.load`` metadata 
is executed, the optimizer may assume the memory location referenced by 
the load contains the same value at all points in the program where the 
memory location is known to be dereferenceable.

Thoughts?

On 8/25/2016 7:23 PM, Hal Finkel via llvm-dev wrote:
> ----- Original Message -----
>> From: "Sanjoy Das" <sanjoy at playingwithpointers.com>
>> To: "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
>> Sent: Thursday, August 25, 2016 6:09:14 PM
>> Subject: Re: [llvm-dev] invariant.load metadata semantics
>>
>> Hi Hal,
>>
>> Hal Finkel via llvm-dev wrote:
>>   > Some questions: Do we allow stores to these locations at all? Only
>>   > if
>>
>> I'd vote for disallowing stores to these locations, but if "stores
>> allowed only if the value is the same" is helpful in some situation
>> then I don't have specific reasons why that would be problematic.
> I would as well; and from what I understand, this is consistent with current use cases.
>
>>   > the value is the same? Must any change be observable to be a
>>   > problem? Do
>>
>> Not sure what you mean by "Must any change be observable".
> If we allow stores, if we have an invariant load from some location, and then a store to that location (value arbitrary), is that a problem if the IR being analyzed never loads from it again? I don't just mean dead stores: just because the IR in question does not load from it again, that does not mean that "the system" doesn't.
>
>>   > atomic loads of invariant locations really need to be atomic?
>>
>> It depends on the answer to "Do we allow stores to these locations at
>> all?".  If we don't allow stores to these locations at all then
>> atomic
>> loads are not required, since we can't have racing stores to that
>> location.
>>
>> However, syntactically, I'd be tempted to allow invariant loads to be
>> atomic; and maybe have a later pass strip out the atomic bit if the
>> semantics we decide allow that.
> I agree. We should allow atomic loads to be marked as !invariant.load. We might, if we decide on semantics that allow it, canonicalize by demoting to a non-atomic load.
>
>   -Hal
>
>> -- Sanjoy
>>

-- 
Geoff Berry
Employee of Qualcomm Datacenter Technologies, Inc.
  Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.