From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10265 invoked by alias); 20 Dec 2007 05:05:38 -0000 Received: (qmail 10246 invoked by uid 22791); 20 Dec 2007 05:05:36 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Dec 2007 05:05:24 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id lBK4wuVR007157; Wed, 19 Dec 2007 23:58:56 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lBK4wu9Q020393; Wed, 19 Dec 2007 23:58:56 -0500 Received: from livre.oliva.athome.lsd.ic.unicamp.br (vpn-14-232.rdu.redhat.com [10.11.14.232]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lBK4wsir014449; Wed, 19 Dec 2007 23:58:55 -0500 Received: from livre.oliva.athome.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by livre.oliva.athome.lsd.ic.unicamp.br (8.14.2/8.14.1) with ESMTP id lBK4wqdt029447; Thu, 20 Dec 2007 02:58:52 -0200 Received: (from aoliva@localhost) by livre.oliva.athome.lsd.ic.unicamp.br (8.14.2/8.14.1/Submit) id lBK4wnKs029446; Thu, 20 Dec 2007 02:58:49 -0200 To: "Daniel Berlin" Cc: "Diego Novillo" , "Mark Mitchell" , "Robert Dewar" , "Ian Lance Taylor" , "Richard Guenther" , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC References: <47671BF4.5050704@google.com> <4aca3dc20712181415y3d5c3717s6d73b1335b311313@mail.gmail.com> <4aca3dc20712182207y648f7bbhab9e0af8ad2ff832@mail.gmail.com> <4aca3dc20712190759g748d6e15pa0e5146c3f5ca0ba@mail.gmail.com> <4aca3dc20712191240r472ee46ekacf32886a1abd63@mail.gmail.com> From: Alexandre Oliva Errors-To: aoliva@oliva.athome.lsd.ic.unicamp.br Date: Thu, 20 Dec 2007 09:26:00 -0000 In-Reply-To: <4aca3dc20712191240r472ee46ekacf32886a1abd63@mail.gmail.com> (Daniel Berlin's message of "Wed\, 19 Dec 2007 15\:40\:11 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2007-12/txt/msg00980.txt.bz2 On Dec 19, 2007, "Daniel Berlin" wrote: >> Now, if z_5 were present in a debug expression, then it would need >> adjusting. No different from the adjusting need for any other >> instruction in which z_5 was present, though. > uh, but if you don't adjust in the fixed examples, DEBUG(x, x_4) will > give an invalid value. My point was that optimizers already had to know how to adjust things such that it doesn't break code. Now, in this optimization, it takes additional liberties with existing variables because it sees they're only used within the sequence. IMHO, it would be more appropriate to introduce alternate temporaries, rather than reusing SSA names for different purposes, in this case. If this approach was taken, the debug annotations referring to a no-longer-defined SSA name would be recognized as invalid, and the variable binding would be removed (i.e., turned into a "value unknown" annotation). Or, if we left the definitions in place, even though they're dead, the same code that cleans up undefined SSA names could recognize these SSA names as unused except in debug information and substitute them for their values, maintaining accurate and complete debug information. But can we do better without introducing more SSA names and keeping assignments around that are known to be dead? Yes, with some additional effort, see below. > How do i know i need to change this DEBUG expression. As reassoc looks for sets of variables it can freely mess with, it should take note of variables that are used in debug annotations in addition to the kind of single (?) non-debug uses it's interested in, such that, when it modifies these variables, the annotations can be compensated for. OTOH, if the compiler performs reassoc on user variables today, it means we do get mangled debug information for such variables already, and they get incorrect values. So, even if we didn't address this problem right away, it wouldn't be much of a regression. But, of course, not dealing with it breaks the goal of having correct debug information, so it ought to be dealt with properly. Do you happen to have a yummy testcase handy that I could use to trigger this kind of transformation in ways that affect the value of user variables? Thanks in advance, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}