Re: [RFC][libitm] Convert to c++11 atomics

[Andrew MacLeod <amacleod at redhat dot com>]

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