From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6947 invoked by alias); 19 Dec 2007 15:59:50 -0000 Received: (qmail 6937 invoked by uid 22791); 19 Dec 2007 15:59:49 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0506.google.com (HELO nz-out-0506.google.com) (64.233.162.233) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Dec 2007 15:59:44 +0000 Received: by nz-out-0506.google.com with SMTP id i11so1725486nzh.26 for ; Wed, 19 Dec 2007 07:59:42 -0800 (PST) Received: by 10.142.104.9 with SMTP id b9mr584940wfc.48.1198079982081; Wed, 19 Dec 2007 07:59:42 -0800 (PST) Received: by 10.142.14.10 with HTTP; Wed, 19 Dec 2007 07:59:41 -0800 (PST) Message-ID: <4aca3dc20712190759g748d6e15pa0e5146c3f5ca0ba@mail.gmail.com> Date: Wed, 19 Dec 2007 16:01:00 -0000 From: "Daniel Berlin" To: "Alexandre Oliva" Subject: Re: Designs for better debug info in GCC Cc: "Diego Novillo" , "Mark Mitchell" , "Robert Dewar" , "Ian Lance Taylor" , "Richard Guenther" , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: <4aca3dc20712182207y648f7bbhab9e0af8ad2ff832@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4766DF5C.1020802@google.com> <47671BF4.5050704@google.com> <4aca3dc20712181415y3d5c3717s6d73b1335b311313@mail.gmail.com> <4aca3dc20712182207y648f7bbhab9e0af8ad2ff832@mail.gmail.com> 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-12/txt/msg00573.txt.bz2 On 12/19/07, Daniel Berlin wrote: > On 12/19/07, Alexandre Oliva wrote: > > On Dec 18, 2007, "Daniel Berlin" wrote: > > > > > Consider PRE alone, > > > > > If your debug statement strategy is "move debug statements when we > > > insert code that is equivalent" > > > > Move? Debug statements don't move, in general. I'm not sure what you > > have in mind, but I sense some disconnect here. > > OKay, so if you aren't going to move them, you have to erase them when > you move statements around. > Besides this, how do you plan on handling the following situations (both of which reassoc performs *right now*). These are the relatively easy ones Here is the easy one: z_5 = a_3 + b_3 x_4 = z_5 + c_3 DEBUG(x, x_4) Reassoc may transform this into: z_5 = c_3 + b_3 x_4 = z_5 + a_3 DEBUG(x, x_4) Now x has the wrong value. At least in this case, you can tell which DEBUG statement to eliminate easily (it is an immediate use of x_4) It gets worse, however c_3 = a_1 + b_2 z_5 = c_3 + d_9 x_4 = z_5 + e_10 DEBUG(x, x_4) y_7 = x_4 + f_11 z_8 = y_7 + g_12 -> c_3 = a_1 + b_2 z_5 = c_3 + g_12 x_4 = z_5 + e_10 DEBUG(x, x_4) y_7 = x_4 + f_11 z_8 = y_7 + d_9 x_4 now no longer represents the value of x, but we haven't directly changed x_4, it's immediate users, or the statements that immediately make up it's defining values. How do you propose we figure out which DEBUG statements we may have affected without doing all kinds of walks? (This is of course, a more general problem of how do i find which debug statements are reached by my transformation without doing linear walks)