[llvm-dev] invariant.load metadata semantics
Caldarale, Charles R via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 25 13:46:17 PDT 2016
> 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.
> 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.
More information about the llvm-dev