From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-59600-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 15175 invoked by alias); 3 Sep 2002 21:25:46 -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 15168 invoked from network); 3 Sep 2002 21:25:45 -0000
Received: from unknown (HELO nile.gnat.com) (205.232.38.5)
  by sources.redhat.com with SMTP; 3 Sep 2002 21:25:45 -0000
Received: by nile.gnat.com (Postfix, from userid 338)
	id 6E76BF2DA6; Tue,  3 Sep 2002 17:25:45 -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: <20020903212545.6E76BF2DA6@nile.gnat.com>
Date: Tue, 03 Sep 2002 14:25:00 -0000
From: dewar@gnat.com (Robert Dewar)
X-SW-Source: 2002-09/txt/msg00110.txt.bz2

<<Than you need to use a wide variety of encoders to avoid this problem.
Also since the source code for gcc is freely available such a thing will
not go unnoticed for long. I seams that you are trying to say that making
tight loops run fast is a pointless exercise by the compiler.  If a large
number of programs tend to use a particular type of loop than optimizing
for those loops would be a huge win in terms of performance.
>>

There are plenty of benchmarks in SPEC and in other standard suites that
have tight loops. So you are misinterpreting my remarks entirely.

The point is that benchmarks are designed to be good as benchmarks, the issue
of whether they perform a useful calculation that lots of people run a lot of
the time is quite besides the point. I would guess that you have not even
studied the SPEC suite closely before you made remarks about it :-)