From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7103 invoked by alias); 3 Sep 2002 21:12:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7096 invoked from network); 3 Sep 2002 21:12:28 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 3 Sep 2002 21:12:28 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g83LCRm11580 for ; Tue, 3 Sep 2002 14:12:27 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Sep 2002 14:12:18 -0700 Received: from johada.apple.com (johada.apple.com [17.201.20.167]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g83LCEb18616; Tue, 3 Sep 2002 14:12:14 -0700 (PDT) Date: Tue, 03 Sep 2002 14:12:00 -0000 Subject: Re: [GCC 3.x] Performance testing for QA Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Dale Johannesen , kevina@gnu.org, Peter.Sasi@t-systems.co.hu, aj@suse.de, gcc@gcc.gnu.org, tjw@omnigroup.com To: dewar@gnat.com (Robert Dewar) From: Dale Johannesen In-Reply-To: <20020903205525.B8861F2941@nile.gnat.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00107.txt.bz2 On Tuesday, September 3, 2002, at 01:55 PM, Robert Dewar wrote: > < 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...