[cfe-commits] [PATCH] atomic operation builtins, part 1

Andrew MacLeod amacleod at redhat.com
Thu Oct 13 12:19:29 PDT 2011

On 10/13/2011 02:36 PM, John McCall wrote:
>> 1)
>> Actually, the generic interface breaks if the atomic type is not the same size as the base type.
>> void __atomic_exchange (size_t size, void *ptr, void *expected, void *desired,...);
>> in reality, from GCC's point of view, it currently doesn't distinguish an atomic type from the base type, it just sees:
>> void __atomic_exchange(T *ptr, T *expected, T *desired, …)
>> if 'expected' and 'desired' were different sizes than 'ptr', we'd need another size parameter and have to deal with padding code, and I'm not prepared to go down that road just yet.
> I'm not sure why you're implementing this intrinsic without having _Atomic types yet.  The intrinsic should really be taking an _Atomic(T)* and two Ts.  That also conveniently removes the need for a size parameter.
> Obviously, it's your call, but…

Well, the size parameter only exists for the external library where 
there is one entry point and it needs to be able to operate on all 
different sizes of objects.  Within the the compiler we simply see the 
types and know what the sizes are... in fact, when calling the external 
routine, the size has to be added by looking at the type.

GCC's existing __sync atomic primitives simply operate on a hunk of 
memory, and these primitives map down to registers.  All lock free 
instruction sequences are going to require equal sized register to 
operate on.  The new __atomic primitives build on top of those, and add 
the memory model. The next release will probably see the old __sync 
routines implemented  in terms of the new __atomic routines rather than 
the way it is now.

When there is a well defined _Atomic modifier which actually changes the 
size, its simple enough to layer this on top of whats there and detect 
the first parameter is a different size, and DTRT, whatever that turns 
out to be.    There is no point in holding up this release or existing 
users when this underlying work is required anyway.

I expect that when _Atomic(T) and T are different sizes, its the caller 
thats going to have to do any padding to make them match, not the atomic 
routine itself...  well, I suppose even that may be up for debate at 
this point.


More information about the cfe-commits mailing list