<p dir="ltr">Sanjoy, can you clarify this bit about JVM array lengths?</p>
<p dir="ltr">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?</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">-Justin</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Aug 25, 2016 7:13 PM, "Sanjoy Das via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Charles,<br>
<br>
Caldarale, Charles R via llvm-dev wrote:<br>
>> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists<wbr>.llvm.org</a>] On Behalf Of Hal Finkel via llvm-dev<br>
>> Subject: Re: [llvm-dev] invariant.load metadata semantics<br>
><br>
>> Alternatively, we might phrase this as: The optimizer may assume that all values loaded<br>
>> from a location, where any of the loads are tagged with !invariant.load, are identical.<br>
><br>
<br>
> 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.<br>
<br>
That is a very defensible point, but depending on your use case you<br>
consider these "initial" writes part of making the memory<br>
dereferenceable.  For instance, for us (JVM) loading array lengths<br>
satisfy the requirements of invariant loads, and we bake in the length<br>
of the array as part of the array's allocation routine.  LLVM never<br>
"sees" a store the the length field of an array.<br>
<br>
However, I can imagine more complex use cases for which the above<br>
approach won't work.<br>
<br>
-- Sanjoy<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>