Re: notes on current atomics config and usage

[Paolo Carlini <pcarlini at suse dot de>]

Hi Benjamin,

> > Indeed, I agree it's a nice idea. I'm only wondering whether the check 
> > itself, in acinclude.m4 could be a little simpler, taking inspiration 
> > from libgomp... Or the additional complexity is related to the annoying 
> > i386  (vs i486 and newer) thing?!?
> >    
> Yes, this config was messed up. I'm still working on a better way to do this...
>
> Thanks for the libgomp pointer.
>
> Turns out the only builtin used is __sync_fetch_and_add. But, even with
> -march=i386, a builtin is used here:
>
> int main()
> {
>  // NB: _Atomic_word not necessarily int. 
>  typedef int atomic_type;
>  atomic_type c1;
>  atomic_type c2;
>  __sync_fetch_and_add(&c1, c2);
> return 0;
> }
>
> ?
>  
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...

> > Well, that's not true: indeed, when  _GLIBCXX_HAVE_ATOMIC_BUILTINS is 
> > defined we *do* inline the calls (for powerpc, ia64, s390, alpha). As a 
> > matter of fact, I introduced the
> > _GLIBCXX_ATOMIC_BUILTINS macro for this very purpose...
> >    
> Ah yes. I didn't realize that everything was going through *_dispatch
> now: nice.
>
> 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. 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.

> Oh, I wish there was a compile-time way to do something like
> __gthread_active_p. Then we could unroll a lot of conditionals....
> avoid a bunch of branching... Anyway. It seems like a link-test a la
> __gthread_active_p is fundamentally at odds with a compile time test
> that we can use do to cool template tricks.
>
> Bummer.
>  
I see your pointer. At least, however, __gthread_active_p is *very* 
cheap (I didn't expect that, at the outset). For some arches, it's a 
compile time constant (-> in such cases conditionalizing on it is 
optimized out and cannot hurt).

Paolo.