Re: gcc 4.1 implements compiler builtins for atomic ops

[Benjamin Herrenschmidt <benh at kernel dot crashing dot org>]

On Sun, 2005-06-26 at 11:53 -0400, Daniel Jacobowitz wrote:
> On Sun, Jun 26, 2005 at 04:36:53PM +1000, Benjamin Herrenschmidt wrote:
> > Well, we have _at_least_ 40x which needs a sync in there, and you really
> > don't want a sync on other processors for performance reasons. As soon
> 
> GCC already supports atomic operations on many platforms.  GCC will
> support the 405CR erratum, next week or so.  David's been working on
> it.
> 
> Let's face it - enough people dislike the overhead of a function call
> for this that if glibc implemented them, they'd be inline functions,
> and you'd have all the same problems.

Yes, but that encourage developers to use them direcltly, which means
that they'll, for example, produce code that will either be broken for
405 or will have a spurrious sync on non-405 which is a significant
performance issue.

There are other problems with the use of atomics, like do you barrier
around atomics that "return" a value ? If not, I can guarantee that 90%
of the people using them will get it wrong.

Finally, as I wrote earlier, a lot of people tend to use atomics to
implement locks. That is totally broken of course in a lot of cases, but
subtely enough that it won't appear unless you do serious testing.
Having that in gcc instead of some library will prevent us from moving
those to the vDSO and thus providing separate implementations for
different CPUs/machines/firmware environment (like a lock that relax a
thread on SMT when spinning, or taking into account 970 issues with
ldarx looops starving the bus, etc....)

I really think it's NOT a good idea to put the atomics in the compiler,
i t's yet another tool that will be used by the vast majority of people
to shoot themselves in the foot for very little benefit.

Ben.