From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23204 invoked by alias); 23 Aug 2005 14:30:42 -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 22932 invoked by uid 22791); 23 Aug 2005 14:29:56 -0000 Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 23 Aug 2005 14:29:56 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j7NETsd7148486 for ; Tue, 23 Aug 2005 14:29:54 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7NETr1C190206 for ; Tue, 23 Aug 2005 16:29:53 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j7NETrch005508 for ; Tue, 23 Aug 2005 16:29:53 +0200 Received: from homer (dyn-9-152-216-41.boeblingen.de.ibm.com [9.152.216.41]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j7NETr42005505; Tue, 23 Aug 2005 16:29:53 +0200 Received: from andreas by homer with local (Exim 3.36 #1 (Debian)) id 1E7Zlm-0000yv-00; Tue, 23 Aug 2005 16:28:54 +0200 Date: Tue, 23 Aug 2005 14:44:00 -0000 From: Andreas Krebbel To: Daniel Berlin Cc: gcc@gcc.gnu.org Subject: Re: Problem with the special live analyzer in global alloc Message-ID: <20050823142854.GA3695@de.ibm.com> References: <20050816135150.GA3617@de.ibm.com> <1124201649.18266.32.camel@MAMBA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1124201649.18266.32.camel@MAMBA> User-Agent: Mutt/1.5.9i X-SW-Source: 2005-08/txt/msg00625.txt.bz2 Hello, sorry for the late answer. > Vlad promised to update it to use df.c once it wasn't "1% slower", which > would make it easily reusable elsewhere, but never did. > Of course, you could reuse it without that, but then someone will > invariably come along and mess with it. Ok I understand that implementing the special lifeness analyzers in global alloc using the df.c framework would ease reusing it somewhere else. But my question was more basic. So do you agree that using one lifeness analyzer for checking what an optimizer step has done based on a second lifeness analyzers output is wrong? If so what is the way to fix this? Going back to the normal analyzer to be used in global alloc would make global alloc creating worse code. But on the other hand using the global alloc lifeness analyzer everywhere else would be a change which nobody would agree with in the current development stage. Because this is a regression from 4.0 to 4.1 this should be fixed as soon as possible. Bye, -Andreas-