[llvm-dev] invariant.load metadata semantics

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Charles R Caldarale" <Chuck.Caldarale at unisys.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org
> Sent: Thursday, August 25, 2016 3:46:17 PM
> Subject: RE: [llvm-dev] invariant.load metadata semantics
> 
> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf
> > Of Hal Finkel via llvm-dev
> > Subject: Re: [llvm-dev] invariant.load metadata semantics
> 
> > Alternatively, we might phrase this as: The optimizer may assume
> > that all values loaded
> > from a location, where any of the loads are tagged with
> > !invariant.load, are identical.
> 
> This would seem to limit the usefulness of the invariant attribute.
>  I would expect invariant to indicate that loads reachable from the
> one marked invariant are guaranteed to read the same value, but that
> prior ones are not.  This would allow updates to be made to the
> location of interest up to the point of declared invariance, but not
> after.

No, this is a different use case, and we invariant.group/invariant.group.barrier and invariant.start/invariant.end for that.

 -Hal

> 
> > This has the benefit of covering the fact that no outside entity
> > (i.e. the operating system)
> > changes the value, and that we can change it, but only to the same
> > value it had before (if
> > we'll later be able to observe the difference).
> 
> > Some questions: Do we allow stores to these locations at all? Only
> > if the value is the same?
> > Must any change be observable to be a problem?
> 
> An alternative semantic is that a store would remove the invariant
> attribute for subsequent loads.
> 
> > Do atomic loads of invariant locations really need to be atomic?
> 
> Ordering would still seem to be important, unless invariant applies
> function-wide with no reachability concerns.
> 
>  - Chuck
> 
> 

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