From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32463 invoked by alias); 24 Jun 2010 13:21:03 -0000 Received: (qmail 32451 invoked by uid 22791); 24 Jun 2010 13:21:02 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Jun 2010 13:20:58 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 4C02ACB02AC; Thu, 24 Jun 2010 15:21:04 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F++DVj-Ww1Nf; Thu, 24 Jun 2010 15:21:04 +0200 (CEST) Received: from [192.168.1.2] (bon31-9-83-155-120-49.fbx.proxad.net [83.155.120.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 29F9BCB02A4; Thu, 24 Jun 2010 15:21:04 +0200 (CEST) From: Eric Botcazou To: Bernd Schmidt Subject: Re: combine/dce patch for PR36003, PR42575 Date: Thu, 24 Jun 2010 14:27:00 -0000 User-Agent: KMail/1.9.9 Cc: gcc-patches@gcc.gnu.org References: <4C20938E.2060606@codesourcery.com> <201006241453.22378.ebotcazou@adacore.com> <4C2356D9.7010606@codesourcery.com> In-Reply-To: <4C2356D9.7010606@codesourcery.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201006241516.38790.ebotcazou@adacore.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-06/txt/msg02460.txt.bz2 > I can tack it onto something else, but I don't see how this would reduce > the amount of work we need to do? The overhead of traversing the RTL or invoking DF isn't negligible so if we can avoid doing it one more time... Steven's measurements showed that the RTL optimizers still consume 40-45% of the compilation time at -O2. -- Eric Botcazou