From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-101585-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 27249 invoked by alias); 30 Aug 2004 10:44:20 -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 27200 invoked from network); 30 Aug 2004 10:44:17 -0000
Received: from unknown (HELO polimi.it) (131.175.12.8)
  by sourceware.org with SMTP; 30 Aug 2004 10:44:17 -0000
Received: from gnu.org (paride.rett.polimi.it [131.175.65.135])
	by polimi.it (8.13.1/8.13.1) with ESMTP id i7UAiFbL017189;
	Mon, 30 Aug 2004 12:44:15 +0200
Message-ID: <41330611.9020600@gnu.org>
Date: Mon, 30 Aug 2004 11:02:00 -0000
From: Paolo Bonzini <bonzini@gnu.org>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: Giovanni Bajo <giovannibajo@libero.it>
CC: gcc@gcc.gnu.org
Subject: Re: GCC 3.5 Status (2004-08-29)
References: <4132641E.3030206@codesourcery.com> <200408300148.54421.stevenb@suse.de> <41326EBF.9020501@codesourcery.com> <200408300229.13652.stevenb@suse.de> <41327A88.5080903@codesourcery.com> <023b01c48e35$0f5ef9f0$8f432597@bagio>
In-Reply-To: <023b01c48e35$0f5ef9f0$8f432597@bagio>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.8.29.111538
X-PerlMx-Spam: Gauge=%%XPROB%%IIIIIII, Probability=7%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000'
X-SW-Source: 2004-08/txt/msg01475.txt.bz2

 > There was agreement that these would be
> tackled after the merge, possibly by running a couple of cleanup optimization
> passes (DCE/CCP).

CFG-transparent expansion did introduce a cleanup pass at -O0, because 
the cleanup that is done while the CFG is built, is now done at -O0 as 
well.  This is responsible of the -O0 3-4% speed increase brought in by 
CFG-transparent expansion.

Paolo