From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25402 invoked by alias); 23 Apr 2002 16:33:31 -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 24673 invoked from network); 23 Apr 2002 16:33:03 -0000 Received: from unknown (HELO kiruna.synopsys.com) (204.176.20.18) by sources.redhat.com with SMTP; 23 Apr 2002 16:33:03 -0000 Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170]) by kiruna.synopsys.com (Postfix) with ESMTP id A5B3CF447; Tue, 23 Apr 2002 09:32:59 -0700 (PDT) Received: from atrus.synopsys.com (localhost [127.0.0.1]) by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id JAA06452; Tue, 23 Apr 2002 09:33:07 -0700 (PDT) From: Joe Buck Received: (from jbuck@localhost) by atrus.synopsys.com (8.9.3+Sun/8.9.1) id JAA20650; Tue, 23 Apr 2002 09:32:58 -0700 (PDT) Message-Id: <200204231632.JAA20650@atrus.synopsys.com> Subject: Re: GCC 3.1 Prerelease To: mark@codesourcery.com (Mark Mitchell) Date: Tue, 23 Apr 2002 09:36:00 -0000 Cc: pfeifer@dbai.tuwien.ac.at (Gerald Pfeifer), gcc@gcc.gnu.org (gcc@gcc.gnu.org) In-Reply-To: <20670000.1019578156@gandalf.codesourcery.com> from "Mark Mitchell" at Apr 23, 2002 09:09:17 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg01178.txt.bz2 Gerald writes: > > As promised, I performed tests comparing GCC 2.95.3, GCC 3.0, GCC 3.0.3, > > the 3.1-branch as of yesterday, the 3.1-branch with -finline-limit=800 > > and 1200, respectively, and the 3.2-branch as of yesterday. > > Thanks very much for doing this. > > The good news is that your code compiles and runs. > > I don't think we're in a position to do much at this point. The numbers > look only slightly different from GCC 3.0.x. There are even some > improvements assuming that smaller numbers in your benchmark table > imply better results. It's still a performance regression from 2.95.x, but as you say it looks like a wash with respect to 3.0.4. I have other test cases where 3.1 does about as well as 2.95.x. Only in very C-like code do we really see improvements in 3.1. > I agree that we should investigate these issues, but I don't think we > should hold up the release to try to work on them. Any fixes will probably need architectural changes that will need extensive testing, so it really isn't feasible. If we're going to do something, I think that we should consider insisting on performance improvements in 3.2, otherwise we do mandatory schedule slips for as long as it takes. There's no point in continuing down the track we're on: releases that take longer and longer to compile code that is no better. (but then didn't we say something like that about 3.1? Sigh) I think Gerald's right: the problem seems to be that the new inliner sucks for some reason. 3.1 does have many bug fixes and C on x86 is faster, so I think it's releasable (modulo the last few high-priority bugs).