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

[Andrew MacLeod]

On 10/11/2011 10:01 PM, Eli Friedman wrote:
>
> On another random ABI note, do you plan on supporting lock-free
> operations on types whose ABI alignment is less than their size?  I'm
> guessing you're planning on requiring alignment equal to the size for
> atomic operations on types with a small power-of-two size regardless
> of the ABI alignment; otherwise, the proposed signature of
> __atomic_is_lock_free won't work.  What about for types whose size is
> small and not a power of two?
>

Current plan is to simply revert to the generic library call if it isnt 
the right size.  Wrong alignment I hadn't really thought of, it should 
probably be illegal I guess.    In most cases, the compiler is going to 
give us a nicely aligned hunk of memory, and if thats not what were 
getting then the client has decided to pack something, or play some 
other little fancy trick.   I'm not even sure how to do a 3 byte lock 
free atomic write short of load, mask, compare and swap loop. It reeks 
of the bitfield data race crud.  Let the library take care of it, or 
maybe even dissallow it...   thoughts?  My first instinct is to just 
pass it on to the library to handle...
>> I've updated the last section of that wiki page to explicitly lay out what
>> I'm thinking:
>>
>> http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary#GCC_intrinsics
> The one substantial difference here between your proposal and what I
> am currently implementing is the type of the pointer argument.  In my
> current implementation, it has type _Atomic(T)* (where _Atomic comes
> from the C1x specification). This encodes in the type system the
> requirement that the argument must be an atomic variable
> (appropriately aligned, etc.).  Sort of related to the ABI questions
> above.
>

we have no _Atomic types as yet. It was in a while ago, then it was 
taken out. I don't know where it lies now.

If it maps to aligned powers of 2,  or typical structure alignments for 
their size, that really what we are saying for the library anyway.  I 
will add that comment in there somewhere.  does that work? I dont think 
the library can be used for something that doesn't map to 'atomic 
alignments'.  Otherwise,  as you say, the is_lock_free(size) breaks.   
Im not sure we need to cater to abnormal alignments, I doubt it would 
buy us much for the hassle.

> The other differences are minor: my current implementation has
> signatures like "T __atomic_load(_Atomic(T)*, int)" for atomic load,
> etc. and there are separate __atomic_compare_exchange_weak and
> __atomic_compare_exchange_strong.  Easy to change either way.
>
As I get them finished, I also may decide differently along the way for 
the builtins... the bool weak parameter is more aimed at reducing the 
rtl patterns and such that are required by porters, but the real 
differences are marginal.  It may turn out that changing the parameter 
list is annoying, and I'll revert back to 2 different builtins :-)

I didn't see the point in putting a weak version in the library.

I'm trying to have the main GCC stuff wrapped in the next week or two so 
we can merge it into mainline for 4.7.   So I wont be vague and waffley 
for long on these :-)

Andrew