[llvm-dev] invariant.load metadata semantics

[Justin Lebar via llvm-dev]

Sanjoy, can you clarify this bit about JVM array lengths?

Presumably the same pointer can point to two arrays of different lengths
during a program's execution.  Does this mean that you're relying on
invariant.load having function scope?  That is, correctness depends on the
pointer not being reused for an array of a different length between the
first invariant load of that array length in a function and the last
(possibly not invariant) load in the function?

This seems like a very weak form of invariance.  For example, when you
inline, you would have to transform invariant loads to the scoped invariant
thing.

In NVPTX I am on a quest to use invariant loads for loads that must never
change during the execution of a kernel.  If the metadata signaled this
more restricted scope, I guess I'd have to figure something else out.

-Justin

On Aug 25, 2016 7:13 PM, "Sanjoy Das via llvm-dev" <llvm-dev at lists.llvm.org>
wrote:

> Hi Charles,
>
> Caldarale, Charles R via llvm-dev wrote:
> >> 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.
>
> That is a very defensible point, but depending on your use case you
> consider these "initial" writes part of making the memory
> dereferenceable.  For instance, for us (JVM) loading array lengths
> satisfy the requirements of invariant loads, and we bake in the length
> of the array as part of the array's allocation routine.  LLVM never
> "sees" a store the the length field of an array.
>
> However, I can imagine more complex use cases for which the above
> approach won't work.
>
> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160829/07563ccf/attachment.html>