From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30855 invoked by alias); 4 Dec 2002 22:00: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 30843 invoked from network); 4 Dec 2002 22:00:28 -0000 Received: from unknown (HELO mx2.redhat.com) (12.150.115.133) by sources.redhat.com with SMTP; 4 Dec 2002 22:00:28 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id gB4LvBa05721; Wed, 4 Dec 2002 16:57:11 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gB4M0Cs06401; Wed, 4 Dec 2002 17:00:12 -0500 Received: from dhcp-172-16-25-153.sfbay.redhat.com (dhcp-172-16-25-153.sfbay.redhat.com [172.16.25.153]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gB4M0C729860; Wed, 4 Dec 2002 14:00:12 -0800 Subject: Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...) From: Eric Christopher To: Neil Booth Cc: Jan Hubicka , Joe Buck , Diego Novillo , Mark Mitchell , Benjamin Kosnik , Gabriel Dos Reis , "pcarlini@unitus.it" , "libstdc++@gcc.gnu.org" , gcc@gcc.gnu.org In-Reply-To: <20021204213956.GD3050@daikokuya.co.uk> References: <20021204194110.GA13428@tornado.toronto.redhat.com> <200212042054.gB4Ksb008847@piper.synopsys.com> <20021204210809.GO5173@kam.mff.cuni.cz> <20021204213956.GD3050@daikokuya.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 04 Dec 2002 14:00:00 -0000 Message-Id: <1039035808.6954.104.camel@ghostwheel.ges.redhat.com> Mime-Version: 1.0 X-SW-Source: 2002-12/txt/msg00234.txt.bz2 On Wed, 2002-12-04 at 13:39, Neil Booth wrote: > Jan Hubicka wrote:- > > > Compiler is getting slower in each release but that is mostly cumulative > > result of adding new features current infrastructure can't accept > > cheaply... > > I hate this slowness. There's no reason IMO that GCC couldn't be 4 > times faster than it is, without any PCH or anything. A lot of the > code we use is just awfully inefficient. And people are working on > more interesting things than fixing some of the real problems we have. > Some of the advantages to working on the tree-ssa bits is that they will (hopefully) enable us to do a better job of optimizing faster so that the later rtl routines have less to work with and are faster as a result. -eric -- Yeah, I used to play basketball...