[llvm-dev] invariant.load metadata semantics

[Hal Finkel via llvm-dev]

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory