Re: notes on current atomics config and usage

[Benjamin Kosnik <bkoz at redhat dot com>]

> Sorry, I'm not sure to get your point: you mean, a builtin *seem* 
> available on i386 whereas it shouldn't? Very strange, indeed... Well, in 
> libgomp a link test is used, that seems a very safe way to go... 
> Probably you want also to have a look to libgfortran...

My test was wrong.

If we can do a non-link test here, we can have a more strait-forward
test that can be used for native and cross compiles. I think this is an
advantage.

Fixed in the attached patch.

> >Still though, I think there is room for improvement here: it would be
> >nice to figure out a way for so_7 where __exchange_and_add and
> >__atomic_add don't have to be exported when the builtins are being used.
> >  
> >
> Definitely, you are 100% right. I haven't been able to get rid of the 
> exports in mainline because of the ABI, in v7 we can. 

Yep. 

>At least, however, 
> mainline is making progress performance-wise, and, as soon as someone ;) 
> provides a preprocessor builtin sensitive to -march= we can even do 
> better, within the current ABI.

Here's another approach.

The attached patch clarifies the atomics config. In a nutshell, if
there exists a config/cpu/*/atomicity.h file, it's used. If there
isn't, either the builtins are used (and inlined) if they are proved to
exist, or the mutex fall-back is used. 

There should never be the case where the cpu has both builtins and a
configure atomicity.h. Thus, this patch removes
config/cpu/i486 because the builtin atomics for this cpu are better.

As-is, this changes the default behavior for default x86 compiles. What
happens? Well, say the host is i686, check. But, the i386 atomicity.h
is skipped over, and there is no i686 atomicity.h, since there are
actually builtins for this host. However, the check for builtins fails,
since the default -march for this host is i386. Thus, mutex-ville.

I think this gives us a more honest configure, without the special-case
hacks.

I realize reasonable people may differ.

As a bonus:

make CXXFLAGS="-march=i686"; make check

works as expected. (ie, builtin atomics are used, and tested.)

Anyway. I'll wait for comments on this. In the long run, I think this is what we want.

I did some performance testing, original vs. patch +
CXXFLAGS="-march=i686". Results are attached. Surprisingly, there is
some slight degradation, but I have not examined it in detail yet. I
didn't expect any change, but the compiler flags are not the same, so
I don't think this is a controlled test of just the atomics config...

I am wondering if the decision to inline the builtins vs. link the
atomic functions should be more explicit, and controlled via macros
like _GLIBCXX_INLINE_ATOMIC_BUILTINS or something...

tested x86/linux
tested x86/linux CXXFLAGS="-march=i686"

-benjamin

Attachment: p.20060713-1
Description: Text document

Attachment: 20060711-libstdc++-performance.sum
Description: Binary data

Attachment: 20060712-libstdc++-performance.atomic.sum
Description: Binary data