From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1774 invoked by alias); 31 Dec 2002 21:55:58 -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 1763 invoked from network); 31 Dec 2002 21:55:56 -0000 Received: from unknown (HELO mailout6-0.nyroc.rr.com) (24.92.226.125) by 209.249.29.67 with SMTP; 31 Dec 2002 21:55:56 -0000 Received: from doctormoo (syr-24-24-16-193.twcny.rr.com [24.24.16.193]) by mailout6-0.nyroc.rr.com (8.11.6/RoadRunner 1.20) with ESMTP id gBVLthk27409 for ; Tue, 31 Dec 2002 16:55:43 -0500 (EST) Received: from neroden by doctormoo with local (Exim 3.36 #1 (Debian)) id 18TUL9-0000Ww-00 for ; Tue, 31 Dec 2002 16:54:23 -0500 Date: Tue, 31 Dec 2002 16:14:00 -0000 To: gcc@gcc.gnu.org Subject: Re: GCC still getting a lot slower Message-ID: <20021231215422.GA2032@doctormoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Nathanael Nerode X-SW-Source: 2002-12/txt/msg01677.txt.bz2 Paul Jarc said: >Nathanael Nerode wrote: >> Frankly, I don't think we should look at bootstrap time. A number of >> the largest changes in B-I-B were necessary build process changes, which >> are quite likely to slow down the build *of* the compiler, but not the >> performance of the compiler. Or, in other words, "so what?". ;-) > >As someone else noted a while ago, bootstrap times are important >because changes are tested by bootstrapping. So slow bootstraps slow >down all other progress. Yeah. But when I said 'necessary', I meant it; these changes have been on the TODO list forever, and they're correctness issues. >> Can we test compile time change of some *fixed* piece of code, >>perhaps? > >That would also be useful, in its own way. If on the other hand the bootstrap slowdown is due to changes in the way the compiler works -- which would be evidenced by compile time change in a fixed piece of code -- then it's likely to be a bad change which we *can* track down and fix by binary search on the b-i-b branch. The changes made in this regard on B-I-B were fewer, smaller, and less invasive. For instance, the change to every single C file on the tree was a build-process change which shouldn't have affected compiler behavior. (If it did, that's another matter.) --Nathanael