This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [GCC 3.x] Performance testing for QA
- From: Dale Johannesen <dalej at apple dot com>
- To: dewar at gnat dot com (Robert Dewar)
- Cc: Dale Johannesen <dalej at apple dot com>, kevina at gnu dot org, Peter dot Sasi at t-systems dot co dot hu, aj at suse dot de, gcc at gcc dot gnu dot org, tjw at omnigroup dot com
- Date: Tue, 3 Sep 2002 14:12:12 -0700
- Subject: Re: [GCC 3.x] Performance testing for QA
On Tuesday, September 3, 2002, at 01:55 PM, Robert Dewar wrote:
<<The type of operations that encoder decoders use (lots of arithmetic
and
data movement) should somehow be incorporate as a benchmark test gcc
should optimize for. The ideal goal would be to make the code fast
enough
that hand written assembly would not be necessary. Thus using an
encoder as
a benchmark would be beneficial. Even if it concentrates on tight
loops.
You need to remember that it is trivial to make a compiler make any ONE
simple program as fast as optimal assembly language.
How? Simply by recognizing the program, and saying "ah ha, this is
program
number 234c, so replace it by the super efficient asm that Joe wrote".
Now of course doing things this blatantly would be considered
cheating, but
in practice you can do things almost this outrageous in a much more
reserved and non-obvious way.
One of the SPEC92 benchmarks, eqntott, was dominated by a single
function
that looped through a linked data structure. Unrolling the loop the
right
number of times was critical, but you couldn't figure this out
legitimately
because the right number of times depended on the data in the structure,
and that was read in from a file. By the end-of-life of Spec92 every
commercial compiler I know of had special code to recognize this
function
and unroll it the right number of times (in some cases, by emitting
canned
assembly as you suggest). The benchmark was removed in later SPEC's...