This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Implementing atomic load as compare-and-swap for read-only memory


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]