This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: More on memory barriers
- From: Jason Merrill <jason at redhat dot com>
- To: Geoffrey Keating <geoffk at apple dot com>
- Cc: gcc at gcc dot gnu dot org, Benjamin Kosnik <bkoz at redhat dot com>, Richard Henderson <rth at redhat dot com>, David Edelsohn <dje at watson dot ibm dot com>, Jason Merrill <jason at redhat dot com>
- Date: Wed, 15 Sep 2004 17:29:37 -0400
- Subject: Re: More on memory barriers
- References: <xypllfcbl1s.fsf@miranda.boston.redhat.com><E6F54AAC-069E-11D9-B175-0030657EA24A@apple.com>
On Tue, 14 Sep 2004 15:39:12 -0700, Geoffrey Keating <geoffk@apple.com> wrote:
> On 14/09/2004, at 2:25 PM, Jason Merrill wrote:
>
>> 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?
>
> It's certainly the case on PPC.
>
> (I would suggest using 'sync' on the initialization path rather than having
> a 'lwsync' on both paths. Even though 'sync' is more expensive, I would
> expect that the non-initialization path will be much more common.)
Can you point me to a reference for this behavior? I haven't been able to
find anything that talks about effects of synchronization primitives on
other processors.
http://www-106.ibm.com/developerworks/eserver/articles/power4_mem.html
only talks about the effects of the instruction on the processor which
executes it. I also note that the NPTL pthread_once implementation for PPC
includes an isync on the early exit path, as I was suggesting.
Moving on,
http://gee.cs.oswego.edu/dl/jmm/cookbook.html
has a bunch of useful information and links, though it's fairly
Java-centric.
It's not clear to me from the SPARC V9 manual that there's any suitable
membar directive that will suppress load reordering on other processors
under the RMO model--though AFAICT the RMO model is never used, so perhaps
we don't care.
Jason