This is the mail archive of the
mailing list for the GCC project.
Re: Implementing atomic load as compare-and-swap for read-only memory
- From: Richard Henderson <rth at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Torvald Riegel <triegel at redhat dot com>
- Cc: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 3 Jun 2016 09:30:10 -0700
- Subject: Re: Implementing atomic load as compare-and-swap for read-only memory
- Authentication-results: sourceware.org; auth=none
- References: <57514F17 dot 2090007 at foss dot arm dot com> <20160603100300 dot GE7387 at tucnak dot redhat dot com> <1464956769 dot 17104 dot 295 dot camel at localhost dot localdomain> <20160603123226 dot GH7387 at tucnak dot redhat dot com>
On 06/03/2016 05:32 AM, Jakub Jelinek wrote:
A change from wide CAS to locking would be an ABI change I suppose, but
it could also be considered a necessary bugfix if we don't want to write
to read-only memory. Does this affect anything but i686?
Also x86_64 (for 128-bit atomics), clearly also either arm or aarch64
(judging from who initiated this thread), I bet there are many others.
Both arm and aarch64 are not affected. Both use the double-word load-locked
instruction for the atomic load; they simply don't pair it with a
store-conditional in that case.
There's nothing to be done about <= i686, but for recent-ish cpus we should be
able to use either sse or fpu loads. While it's not promised in the spec, I
would suggest that any 64-bit capable cpu will in practice perform all aligned
64-bit loads atomicly.
There's nothing that can be done for x86_64 128-bit load. There are probably
some implementations for which an aligned 128-bit sse load is atomic, but we
also know that there are some implementations for which it is not (those that
split sse instructions into 2 64-bit micro-ops, e.g. some AMD and all Atoms).
It's an oversight that it would be nice for Intel+AMD to fix for us...