On 01/02/2012 01:19 PM, Torvald Riegel wrote:
On Tue, 2011-12-20 at 01:13 +0100, Torvald Riegel wrote:
On Mon, 2011-12-19 at 15:17 -0800, Richard Henderson wrote:
On 12/19/2011 02:58 PM, Torvald Riegel wrote:
In the particular case (the validated loads technique used in
method-gl.cc, load(), store(), and validate()), we actually do not need
to have loads or stores to be really atomic, but need the compiler to
treat them as if they were atomics wrt. to reordering etc. (e.g., wrt.
adjacent fences). Right now, I'm relying on the fact that GCC doesn't
optimize atomics yet and am just using nonatomic loads/stores.
For 4.7, these accesses need to be volatile if they're to interact
with the adjacent atomic ops.
What do you mean by "interact"? AFAIU Andrew, currently atomics act as
full optimization barriers, leaving nonatomic memory accesses in place
somewhere between the surrounding atomic accesses.
Andrew, can you please comment on this?
Thats true until you get to RTL patterns. once the atomics are expanded
to RTL, they are no longer function calls, but are rtl patterns flagged
as instructions with volatile memory references or something like that.
(Im not as 'up' on the RTl side of things...) This prevents the rtl
optimizations from doing much with them, WHEN they are related at least.
Im not sure exactly where he is coming from, but my guess is that if
you want those "non-atomic" unrelated loads and stores to never be moved
around past atomics, (especially relaxed atomics), they have to look
like atomics and thats accomplished by being volatile in RTL... (Im
guessing and tp dancing a bit here :-)
any reason you can't just make those loads/stores relaxed atomics?
Andrew
