Re: Call for compiler help/advice: atomic builtins for v3

[Mark Mitchell <mark at codesourcery dot com>]

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