[cfe-dev] atomic builtins

Douglas Gregor dgregor at apple.com
Tue May 5 21:45:58 PDT 2009


On May 5, 2009, at 12:42 PM, 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);
> }

I don't know how we'd model that with overloading. :(

> 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.

#2 seems like the best solution here.

   - Doug



More information about the cfe-dev mailing list