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: Richard Henderson <rth at redhat dot com>
- Cc: Geoffrey Keating <geoffk at apple dot com>, Benjamin Kosnik <bkoz at redhat dot com>, gcc at gcc dot gnu dot org, dje at watson dot ibm dot com, Jason Merrill <jason at redhat dot com>
- Date: Wed, 20 Oct 2004 19:59:40 -0400
- Subject: Re: More on memory barriers
- References: <E6F54AAC-069E-11D9-B175-0030657EA24A@apple.com><xyp3c1kaw6s.fsf@miranda.boston.redhat.com><20040915071741.GB989@redhat.com><xypy8jba66z.fsf@miranda.boston.redhat.com><20040915133559.44ac74c8.bkoz@redhat.com><5CE476FA-074C-11D9-B378-000A95B1F520@apple.com><20040915201141.GC4109@redhat.com><xyp1xh39q84.fsf@miranda.boston.redhat.com><20040915213619.GA4634@redhat.com><xypvfef8ag7.fsf@miranda.boston.redhat.com><20040916003604.GA4832@redhat.com>
Digging up this issue...
On Wed, 15 Sep 2004 17:36:04 -0700, Richard Henderson <rth@redhat.com> wrote:
> On Wed, Sep 15, 2004 at 05:54:32PM -0400, Jason Merrill wrote:
>> > For i386 and ia64, speculation is canceled by cache probes.
>>
>> OK. Can you point me at the relevant documentation?
>
> For ia64, speculation is under direct user control.
> [citations]
Then perhaps "speculation" is the wrong term for the out-of-order execution
I'm worried about. The compiler can certainly avoid speculation across a
memory clobber.
4.4.7 says,
Memory data access ordering must satisfy read-after-write (RAW),
write-after-write (WAW), and write-after-read (WAR) data dependencies to
the same memory location. In addition, memory writes and flushes must
observe control dependencies. Except for these restrictions, reads,
writes, and flushes may occur in an order different from the specified
program order.
There's (a lot) more detail about the relaxed ordering model in volume 2,
section 2. I don't see anything to suggest that anything done by one
processor would impose an ordering on another processor; therefore, it
seems that we need to test the flag using ld.acq.
BTW, we had a presentation at the C++ committee meeting Monday night
talking about changes to the C/C++ memory model to support threaded
programs. One proposed change was to give release semantics to volatile
writes and acquire semantics to volatile reads. With that change, making
the sentinel volatile would make this stuff work.
Jason