[cfe-dev] atomic builtins

[Howard Hinnant]

On May 5, 2009, at 11:42 AM, Chris Lattner wrote:

> Hi All,
>
> I'm looking into implementing the atomic builtins correctly.  These
> are documented here:
> http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html#Atomic-Builtins
>
> A funny thing of these is that they are overloaded (arg).  This means
> that code that calls __synch_fetch_and_add with an int ends up calling
> __synch_fetch_and_add_4, for example.  It also
>
>
> I see a couple of ways to implement this:
>
> 1. Expand the attribute overloadable stuff to work from builtins.td
> somehow.  I'm not sure how to extend builtins.td to handle this, and
> I'm also not sure how overloading can reasonably handle insane cases
> like this (without enumerating every possible pointer type?):
>
> int *test(int *A, int **P) {
>   return __sync_fetch_and_add(P, A);
> }
>
> If we could get this resolved into a different builtin id for every
> width, the code generator could do the right thing.
>
> 2. Add all the versions (with the name suffixes) to the builtins.td
> file and have sema change the AST (introducing casts and a new callee)
> when it analyzes the call.
>
> 3. Add just the overloaded version of the builtin to the builtins.def
> file, and make sema change it into a new AtomicExpr node.  This would
> be better than #2 for representing the source level construct.
>
> Does anyone have an opinion on this?  I'm not exactly sure what is
> required to get #1 working.  If that can't work, I tend to think that
> #3 is best.

I don't have an opinion on your question directly.  However I advise  
when working this area to consider the C++ atomics interface as it  
contains a C interface which WG14 (the C committee) is likely to adopt  
(the two committees are attempting cooperation in this area).  The  
latest C++ spec can be found here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf

Search for "[atomics]".

I am not (yet) terribly familiar with this part of the C++ standard.   
But I know the authors well, and I know that their intent is to create  
an interface that serves both C and C++ languages equally well.  If  
there is latitude in the gcc spec which allows aligning more closely  
with the C/C++ spec, I think it would be good to take advantage of  
that latitude.

-Howard