Call for compiler help/advice: atomic builtins for v3

[Paolo Carlini]

Mark Mitchell wrote:

>Paolo Carlini wrote:
>
>>Actually, the situation is not as bad, as far as I can see: the worst
>>case is i386 vs i486+, and Old-Sparc vs New-Sparc. More generally, a
>>targer either cannot implement the builtin at all (a trivial fall back
>>using locks or no MT support at all) or can in no more than 1
>>non-trivial way. 
>>    
>>
>Are you saying that you don't expect there to ever be an architecture
>that might have three or more ways of doing locking?  That seems rather
>optimistic to me.  I think we ought to plan for needing as many versions
>as we have CPUs, roughly speaking.
>  
>
Yes, in principle you are right, but in that case we can reorder the
ifs: first i686, last i386 ;) Seriously earlier today I was hoping we
can have something smarter than a series of conditionals at the level of
libgcc, I don't know it much. I was hoping we can manage to install a
version of it "knowing the target", so to speak.

>As for the specific IA32 case, I think you're suggesting that we ought
>to inline the sequence if (at least) -march=i486 is passed. If we
>currently use the same sequences for all i486 and higher processors,
>then that's a fine idea; there's not much point in making a library call
>to a function that will just do that one sequence, with the only benefit
>being that someone might later be able to replace that function if some
>as-of-yet uknown IA32 processor needs a different sequence.
>
Yes. My point, more correctly, is that, when -march=i486+ is passed,
*nothing* would change compared to what happens *now*. Again, I don't
know the details of Richard's implementation but the real new things
that we are discussing today kick-in when i386 (the default) is in effect.

Paolo.