From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-59592-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 31388 invoked by alias); 3 Sep 2002 20:55:26 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 31381 invoked from network); 3 Sep 2002 20:55:26 -0000
Received: from unknown (HELO nile.gnat.com) (205.232.38.5)
  by sources.redhat.com with SMTP; 3 Sep 2002 20:55:26 -0000
Received: by nile.gnat.com (Postfix, from userid 338)
	id B8861F2941; Tue,  3 Sep 2002 16:55:25 -0400 (EDT)
To: dewar@gnat.com, kevina@gnu.org
Subject: Re: [GCC 3.x] Performance testing for QA
Cc: Peter.Sasi@t-systems.co.hu, aj@suse.de, gcc@gcc.gnu.org,
	tjw@omnigroup.com
Message-Id: <20020903205525.B8861F2941@nile.gnat.com>
Date: Tue, 03 Sep 2002 13:55:00 -0000
From: dewar@gnat.com (Robert Dewar)
X-SW-Source: 2002-09/txt/msg00102.txt.bz2

<<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.

So a benchmark that has a single inner loop that takes most of the time
is almost always a bad idea.