Call for compiler help/advice: atomic builtins for v3
Mark Mitchell
mark@codesourcery.com
Sun Nov 6 18:39:00 GMT 2005
Paolo Carlini wrote:
> Hi,
>
> we have this long standing issue which really we should solve, one way
> or another: otherwise there are both correctness and performance issues
> which we cannot fix, new features which we cannot implement. I have
> plenty of examples, just ask, in case, if you want more details and
> motivations.
I think this is a somewhat difficult problem because of the tension
between performance and functionality. In particular, as you say, the
code sequence you want to use varies by CPU.
I don't think I have good answers; this email is just me musing out loud.
You probably don't want to inline the assembly code equivalent of:
if (cpu == i386) ...
else if (cpu == i486) ...
else if (cpu == i586) ...
...
On the other hand, if you inline, say, the i486 variant, and then run on
a i686, you may not get very good performance.
So, the important thing is to weigh the cost of a function call plus
run-time conditionals (when using a libgcc routine that would contain
support for all the CPUs) against the benefit of getting the fastest
code sequences on the current processors.
And in a workstation distribution you may be concerned about supporting
multiple CPUs; if you're building for a specific hardware board, then
you only care about the CPU actually on that board.
What do you propose that the libgcc routine do for a CPU that cannot
support the builtin at all? Just do a trivial implementation that is
safe only for a single-CPU, single-threaded system?
I think that to satisfy everyone, you may need a configure option to
decide between inlining support for a particular processor (for maximum
performance when you know the target performance) and making a library
call (when you don't).
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304
More information about the Libstdc++
mailing list