Possible subtle memory model error in ClassValue
hboehm at google.com
Tue Aug 11 17:06:15 UTC 2020
I think the relevant statement is:
"An address dependency between two reads generated by SVE vector load
instructions does not contribute to the Dependency-ordered-before relation."
This is only an issue if BOTH loads are SVE loads. In particular reference
loads have to be vectorized for this to matter, which I expect is not the
common situation. I have not explored this in great detail, but it should
suffice to put fences between two dependent vector reference loads, and
between a reference load and a dependent final field load.
On Tue, Aug 11, 2020 at 6:17 AM Andrew Haley <aph at redhat.com> wrote:
> On 11/08/2020 12:03, Andrew Dinn wrote:
> > You ought to look at the pdf Ningsheng linked in the RFR that was posted
> > with the SVE patch. The pdf is available here:
> > https://developer.arm.com/docs/ddi0584/latest
> > The relevant text is in section 4.4. Memory Ordering.
> That looks better than I feared. The only relevant text here AFAIUI is
> "If an address dependency exists between two memory reads, and an SVE
> non-temporal vector load instruction generated the second read, then
> in the absence of any other barrier mechanism to achieve order, the
> memory accesses can be observed in any order by the other observers
> within the shareability domain of the memory addresses being
> ... but this is only about non-temporal vector load instructions. It
> does mean that if we want to use those we'll have to separate them
> from loads of base addresses with fences.
> So it'll be
> Load base register
> load fence
> ... vector loop ...
> Andrew Haley (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the core-libs-dev