This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Call for compiler help/advice: atomic builtins for v3
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, rth at redhat dot com, Ian Lance Taylor <ian at airs dot com>
- Date: Sun, 06 Nov 2005 11:02:29 -0800
- Subject: Re: Call for compiler help/advice: atomic builtins for v3
- References: <436DDC36.8070308@suse.de> <436E4DF0.3070004@codesourcery.com> <436E51C4.8060108@suse.de>
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.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304