Re: Call for compiler help/advice: atomic builtins for v3

[Ulrich Drepper <drepper at redhat dot com>]

Mark Mitchell wrote:
> Yes, GLIBC does that kind of thing, and we could do.  In the simplest
> form, we could have startup code that checks the CPU, and sets up a
> table of function pointers that application code could use.

That's not what glibc does and it is a horrible idea.  The indirect
jumps are costly, very much so.  The longer the pipeline the worse.

The best solution (for Linux) is to compile multiple versions of the DSO
and place them in the correct places so that the dynamic linker finds
them if the system has the right functionality.  Code generation issues
aside, this is really only needed for atomic ops and maybe vector
operations (XMM, Altivec, ...).  The number of configurations really
needed and important is small (as is the libstdc++ binary).

So, just make sure that an appropriate configure line can be given
(i.e., add --enable-xmm flags or so) and make it possible to compile
multiple libstdc++ without recompiling the whole gcc.  Packagers can
then compile packages with multiple libstdc++.

Pushing some of the operations (atomic ops) to libgcc seems sensible but
others (like vector ops) are libstdc++ specific and therefore splitting
the functionality between libstdc++ and libgcc means requiring even more
versions since then libgcc also would have to be available in multiple
versions.


And note that for Linux the atomic ops need to take arch-specific
extensions into account.  For ppc it'll likely mean using the vDSO.

-- 
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â

Attachment: signature.asc
Description: OpenPGP digital signature