More on memory barriers

[Jason Merrill]

After further reading, it seems to me that we're going to need read-side
memory barriers on targets besides Alpha.  Alpha may be the only platform
with the odd cache behavior we were describing, but many architectures seem
to support speculative execution, which can result in out-of-order loads.

On the PowerPC platform, for instance, it seems like we need an lwsync
between initializing the variable and setting the guard, and then an isync
after checking the guard to discard the results of any speculative
execution.  A very similar situation is described in

  http://www-106.ibm.com/developerworks/eserver/articles/power4_mem.html

On SPARC we might use a #StoreStore barrier in the initialization path, and
a #LoadLoad barrier in the non-initialization path.

On ia64, a release barrier in the initialization path, and an acquire
barrier in the non-initialization path.

Even more recent x86es seem to support out-of-order execution, at least of
SSE code, and have introduced the sfence/lfence/mfence operations.

Or is it the case on all of these targets that using a more heavyweight
barrier (i.e. sync on PPC) invalidates speculative loads on other
processors?

This also leads me to wonder if the libstdc++ atomicity.h ought to include
memory barrier instructions on more targets, as they do on the alpha and
PPC405 (though, oddly, not for other PPC targets; this seems rather
fragile).  The ia64 __sync_* intrinsics also imply a full barrier.

It also means that my 2003-12-19 change to remove general memory
clobbers from the atomic operations was misguided; I failed to consider the
synchronization function of the memory clobber.

Thoughts?

Jason