From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21614 invoked by alias); 13 May 2003 18:02:16 -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 21568 invoked from network); 13 May 2003 18:02:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 May 2003 18:02:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h4DI2CH21356; Tue, 13 May 2003 14:02:12 -0400 Received: from speedy.slc.redhat.com (vpn50-15.rdu.redhat.com [172.16.50.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4DI29I10004; Tue, 13 May 2003 14:02:09 -0400 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.8/8.12.8/Submit) with ESMTP id h4DI25Ea012586; Tue, 13 May 2003 12:02:06 -0600 Message-Id: <200305131802.h4DI25Ea012586@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: Diego Novillo cc: Zack Weinberg , Michael Matz , "gcc@gcc.gnu.org" Reply-To: law@redhat.com Subject: Re: Dead-code elimination can't remove string copy insns? In-Reply-To: Your message of "13 May 2003 13:50:41 EDT." <1052848240.27232.407.camel@frodo.toronto.redhat.com> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 May 2003 18:02:00 -0000 X-SW-Source: 2003-05/txt/msg01339.txt.bz2 In message <1052848240.27232.407.camel@frodo.toronto.redhat.com>, Diego Novillo writes: >On Tue, 2003-05-13 at 13:38, law@redhat.com wrote: > >> Does this look better? :-) >> >Much :) > >Now, if we could also get rid of those pesky labels. You mentioned >something about that, but I forget what. Well, it's simply a matter of building a use count for the labels. As we remove GOTO_EXPRs we decrement the count. If the count goes to zero and the label is not special (such as the target of a nonlocal goto), then the label is unused and can be eliminated. There's nothing particularly tricky here except that we want to build those use counts efficiently. Meaning we don't want a separate walk over the tree structures merely to build the use counts. It's on the TODO, but it hasn't bubbled up to the top yet. Removal of unused variables is a much bigger win as far as compilation time is concerned. Jeff