[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