Re: notes on current atomics config and usage

[Benjamin Kosnik <bkoz at redhat dot com>]

> > 1) probe for builtins, if found, use
> > 2) if not, look for atomics config, if found, use
> > 3) fall back to mutex
> 
> FWIW, this makes sense to me.  

Thanks. Probably better re-stated as:

1) probe for builtins (honoring -march value if present), if found, use
2) if not, look for atomics config (based on -march value if present), if found, use
3) if none of the above, fall back to mutex

> But, for the atomics config, shouldn't we
> look for atomics that match the -march (whether default or explicit),
> rather than the target triplet?  If the default -march for the compiler
> I build is i386, then don't I want the i386 atomics.h (if it exists)?

Yes, that would make sense. This is exactly where I want to go. The
library has to stop guessing at what people want, stop skirting the
performance implications of the default-configured arch for common
platforms, and get out of the way for people who know what they want.

When you say "explicit -march" I am assuming you are talking about a
CXXFLAGS="-march=foo" type thing. Is there any other way to pass this
info? (CFLAGS, I guess.) There has to be a limit to the number of
variables are scanned looking for this stuff.

Is there a way to get the default -march value from the build compiler?
(If so, please tell!)

> (If that's going to result in bad performance, then I'd suggest we make
> the default arch for i686-pc-linux-gnu be, i486 instead; i.e., change
> the compiler, not the library.)

I would very much like to do this. It looks like you, me, Ian Taylor,
and Paolo are all in agreement here.

One of the weaknesses of the above three-part plan is that with this in
place, and somebody who builds libstdc++ with CXXFLAGS="-march=i686",
then they get the builtin atomics. Cool: this is probably exactly what
they were expecting.

However, if they install this as a system lib then all users are going
to have to use the -march flag exactly as configured or else they'll
get synthesized calls to non-existent builtin atomics functions. (since
without the -march flag the default arch for this platform is i386,
with no builtin atomics.)

In reality, instead of configuring with CXXFLAGS the user should have
just done a local edit to the compiler to change the default arch to
i686. Then the desires of the system builder and the system users will
be aligned.

> Also, were I you, I wouldn't be afraid to modify the compiler to make it
> easier to get information that you need.  For example, add a
> __GCC_ATOMIC_BUILTINS macro that's predefined if we have the builtins,
> or add a -print-features option to the driver that prints out things like:
> 
>  atomic-builtins;tls;hardware-fp;...
> 
> I'm not saying you *should* do this; just that it seems a reasonable way
> to go if dealing with autoconf probes is unreasonably hard.

the configure probes aren't hard: we can just do asm tests for the builtins.

The problem is trying to align the compiler + library.

-benjamin