On 12/20/2011 11:13 AM, 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.
I'm not really certain what I was thinking here. If there are actual fences, then we'll have other optimization barriers in place. The volatility (or not) of the non-atomic operations doesn't enter into it. Sorry for the confusion. r~
