Re: __sync_swap* with acq/rel/full memory barrier semantics

[Andrew MacLeod <amacleod@redhat.com>]

On 05/31/2011 06:38 AM, Jakub Jelinek wrote:
>
>> Aldy was just too excited about working on memory model I think :-)
>>
>> I've been looking at this, and I propose we go this way :
>>
>> http://gcc.gnu.org/wiki/Atomic/GCCMM/CodeGen
>>
>> Please feel free to criticize, comment on,  or ask for
>> clarification.  I usually miss something I meant to get across.
> I think the addition of new __sync_* builtins for the different models
> is preferrable and would be generally more usable even for other users than
> C++ atomics. On some targets any atomic insn will act as a full barrier,
> while on others it could generate different insns or code sequences that
> way.  For OpenMP atomics having a none (in addition to full/acq/rel)
> would be useful, I think #pragma omp atomic doesn't impose any ordering
> on memory accesses other than the memory being atomically
> read/written/changed.  Haven't read the C++0x standard in detail why
> it has 6 memory order modes instead of just 4, but if really 6 are needed
> (even for 4 probably), having new builtins with just one constant extra
> argument which says the memory ordering mode would be best.
>
>
I'm not sure if you are agreeing or not, or how much :-)

There is still only the basics of relaxed, consume, release/acquire, and 
seq-cst.  so there are 4 modes.  C++ gives you two more  by separating 
release and acquire for loads and stores, loads using 'acquire' mode, 
stores using 'release'.  I guess It allows for a slightly finer control 
over instructions that can be loads and/or stores. It looks like the 
optimal powerpc sequence for cmpxchg is slightly more efficient when its 
just an acquire or just a release rather than an acquire/release for 
instance. (and all 3 sequences are slightly different)

The table is more or less complete... ie,  a store cant have an 
'acquire' mode...  and I presume that a consumer which doesn't break 
release-acquire down into component parts would use that 'release' 
version of the store as 'release/acquire' mode.

I presume a single builtin with a parameter is the most efficient way to 
build them, but thats just an implementation detail. Presumable you have 
each builtin in the table with each of those possible modes as a valid 
parameter.   The one thing I would care about is i would like to see the 
relaxed version be 'just an insn' rather than a builtin, if thats 
possible... My understanding is that relaxed (as far as C++) has no 
synchronization at all, so therefore you can treat it like a normal 
operation as far as optimization. That seems the same for openMP.  Its 
just thats its atomic operation.  So it would be preferable if we can 
avoid a builtin in the optimizers for that. Thats why I left it out of 
the table.  If all the atomic operations are already builtins, well, 
then I guess it doesn't matter :-P

It would be nice to say something like   emit_atomic_fetch_add 
(memory_order)  and if its  relaxed, emit the atomic fetch_add insn (or 
builtin if thats what it is), and if its something else, emit the 
appropriate builtin.  That would make bits/libstdc++v2/atomic_2.h even 
easier too

I think maybe we are more or less saying the same thing? :-)

Andrew