atomic builtins

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.

-Chris

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:

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

I think that these can be directly handled with library level support, and they are better thought out than the GCC builtins (e.g. they don't work for arbitrary pointer types, etc). Supporting the two are pretty different.

-Chris

I'm going to start implementing #3.

-Chris

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

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

So, I really meant #3, because we can most easily deal with the variations in the different atomic operations if it's a special AST type like AtomicExpr.

  - Doug

After discussing this on irc, he really really does mean #2 :). I'll work on this tomorrow.

-Chris