From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21416 invoked by alias); 26 Nov 2007 17:05:19 -0000 Received: (qmail 21400 invoked by uid 22791); 26 Nov 2007 17:05:18 -0000 X-Spam-Check-By: sourceware.org Received: from mail.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Nov 2007 17:05:12 +0000 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 6A55121669; Mon, 26 Nov 2007 18:05:10 +0100 (CET) Date: Mon, 26 Nov 2007 18:19:00 -0000 From: Michael Matz To: Alexandre Oliva Cc: Mark Mitchell , Ian Lance Taylor , Richard Guenther , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC In-Reply-To: Message-ID: References: <84fc9c000711050327x74845c78ya18a3329fcf9e4d2@mail.gmail.com> <4732519C.6070802@codesourcery.com> <4733554D.4040402@codesourcery.com> <4737BBBF.3080400@codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00670.txt.bz2 Hi, On Fri, 23 Nov 2007, Alexandre Oliva wrote: > On Nov 13, 2007, Michael Matz wrote: > > > The nice thing is, that there are only few places which really get rid of > > SETs: remove_insn. You have to tweak that to keep the information around, > > not much else (though that claim remains to be proven :) ). > > And then, you have to tweak everything else to keep the note that > replaced the set up to date as you further optimize the code. No. remove_insn() would replace the SET with a note. It would look at other SETs where the information could be put in which is lost. After all, there must have been a reason for the SET to be deleted: the destination is dead, hence whatever user-variables were associated with it also are dead. (if they also lie in other places, those are not affected). So it's okay to completely get rid of the SET and decl associations. One special case of the above is, when a SET is deleted which is a copy, where the LHS was associated with some variables, but the RHS was not. >From that point on we can (under certain circumstances) associate the RHS with the decls (by changing it's initial SET). Ciao, Michael.