On Fri, Jun 03, 2016 at 10:34:15AM +0100, Kyrill Tkachov wrote:
> expand_atomic_load in optabs.c tries to expand a wide atomic load using an
> atomic_compare_and_swap
> with the comment saying that sometimes a redundant harmless store may be
> performed.
> Is the store really valid if the memory is read-only?
>
> I've been looking at implementing a similar compare-and-swap strategy for
> atomic_loaddi for some
> arm targets and this concern came up. I don't think GCC can statically prove
> that a particular
> piece of memory is guaranteed to be writeable at runtime in all cases, so
> emitting a spurious
> store would not be always valid.
>
> I see this concern was already raised in
> https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00278.html
> but that doesn't seem to have gone anywhere.
>
> Any thoughts? Should we remove the assumption that atomic loads always access
> writeable memory?
I guess it is a tough decision. If you don't have HW instruction to read
say double word aligned integer atomically, if you don't implement atomic
load on it through compare and swap (which indeed won't work with read-only
memory), then you probably need to fall back to locks in libatomic.
But doesn't that mean you should fall back to locked operation also for any
other atomic operation on such types, because otherwise if you atomic_store
or any other kind of atomic operation, it wouldn't use the locking, while
for atomic load it would? That would be an ABI change and quite significant
pessimization in many cases.
Jakub
