Call for compiler help/advice: atomic builtins for v3

[Richard Guenther]

On 11/6/05, Mark Mitchell <mark@codesourcery.com> 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.
>
> 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.

Just to put some more thoughts on the table, I'm about to propose adding
a __gcc_cpu_feature symbol to $suitable_place, similar to what Intel is
doing with its __intel_cpu_indicator which is used in their runtime libraries
to select different code paths based on processor capabilities.  I'm not
yet sure if and how to best expose this to the user, but internally this could
be mapped 1:1 to what we have in the TARGET_* flags.

Richard.