[RFC] Fix full memory barrier on SPARC-V8

David Miller davem@davemloft.net
Tue Jun 28 00:52:00 GMT 2011


From: Geert Bosch <bosch@adacore.com>
Date: Mon, 27 Jun 2011 19:36:06 -0400

> On Jun 27, 2011, at 19:00, David Miller <davem@davemloft.net> wrote:
> 
>> V8 can only reorder stores, that's why it only has a 'stbar'
>> instruction.  I'm not so sure I agree with trying to paper over the
>> fact that someone has compiled code for v8 that's going to run on a v9
>> cpu.
>
> That's not the issue. While it is true that all stores will be
> submitted in order , this does not guarantee store-load
> consistency. In particular on a multiprocessor, each individual
> processor has it's own store buffers and cannot see what is in the
> other CPUs store buffet. In the end all stores will be committed to
> memory in a sequential order, but that is not sufficient. The use of
> a load-store instruction is needed to achieve a full barrier.  The
> SPARC architecture manuals describe this in detail.

I'm trying to find the part of the v8 manual that says there is
a situation where we should use "stbar" and a "ldstub" to implement
proper memory barriers.  In particular I'm looking in Appendix J,
"Programming with the memory models."  Where is the description?

Adding a ldstub here is going to be really expensive, on UltraSparc
that can be 36+ cycles even on a cache hit.

Also, the more I think about it, the issue really is that one is
trying to run v8 code on a v9 cpu.

And this is because no v8 cpu ever implemented anything other than
"Strong Consistency", so on a v8 cpu you would never run into this
problem.

I really think the answer in this situation is "compile code for the
actual processor you're targetting, especially if you want features
with processor specific behaviors, such as atomics and memory
barriers, to work properly."



More information about the Gcc-patches mailing list