More on memory barriers
Jason Merrill
jason@redhat.com
Thu Oct 21 01:17:00 GMT 2004
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
More information about the Gcc
mailing list