notes on current atomics config and usage

[Paolo Carlini]

Hi Benjamin,
>> I see this point in a slightly different way. It all depends on whether 
>> the atomics (implemented in terms of underlying builtins) are part of 
>> the library, i.e., exported, or not. 
>> If they are part of the library, 
>> then the user code, irrespective of the -march, will call into the 
>> library and all will be fine. 
>> If, on the other hand, the atomics are 
>> inlined, then the issue is for our *headers* to recognize the actual 
>> -march (via __GCC_ATOMIC_BUILTINS, I can't see any other way...) and do 
>> the right thing.
>>     
> Options are:
> 1) inline atomics only, no exports
> 2) don't inline any atomics, force link to exported
> 3) inline atomics only and have compatibility exports
>
> The way I see it, every which way we get get into dicy situations.
>
> Option 1:
>
> a) configured for i686, user tries to use with -march="-i386". This
> will blow up, regardless of __GCC_ATOMIC_BUILTINS, because of the
> inlined builtins in the *.cc files compiled into libstdc++.a or libstdc+
> +.so have instructions not on this arch. Thus, any linkage will fail.
>   
Agreed. The problem essentially is interoperability between library code 
and user code (with i386, user code tries to use mutexes, and the 
library code atomic builtins)
> b) configured for i386, user tries to use with -march="i686". This
> will not blow up, but won't be optimal because all the library bits are 
> compiled without the advanced atomics. The user will only get the
> builtins on header files.
>   
I think it will not work at all, for reasons similar to a)

In any case, Option 1 is only academic, at the moment, because we have 
to export anyway, and consistently, because of the ABI...
> Option 2:
>
> a) configured for i686, user tries to use with -march="-i386". Blow up.
> Possible work around would be to put just the atomics in a separate
> library, which is dynamically selected based on the -march value in
> use. This won't work for anything except for toy projects.
>   
Here I disagree. Why blow up? The library has been compiled in a 
consistent way, and the compiler expanded inline the builtins as part of 
the code generation of the exported atomics. The latter are exported and 
called by the user code. As I said earlier today, the only problem I 
could see, in principle, would ensue from calling conventions different 
for i386 and i686, but I don't think this is the case: in fact,  right 
now, we can certainly build the library passing i686 and then link 
default compiled (i386) user code to it (you did that yesterday, for 
example).
> b) configured for i386, user tries to use with -march="i686". Won't get
> benefit of atomics, -march is a no-op.
>   
Definitely, the slow (suited for i386) atomics are called.
> Option 3:
> all the issues with Option 1.
>
> Let's face it: i486+ and i386 are related, but separate arches. Same
> for sparc families.
>   
I agree ;) The main problem is:
1- We don't want to build two times the packages of our distributions.
2 (secondary) - We have an ABI and compulsory exports.

Otherwise, AFAICT, we could inline smartly (we almost did that, without 
the builtins, back in 3.2 times or so...)

Thus, I think we have to live with exported atomics, no inlines for 
i386/1686. However, when we build the library I think it's ok to exploit 
the underlying builtins, if available: that means query the target, the 
triple, or, as Mark pointed out, the actual -march=, passed in CXXFLAGS.

Paolo.