From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4825 invoked by alias); 27 Nov 2007 00:14:17 -0000 Received: (qmail 4812 invoked by uid 22791); 27 Nov 2007 00:14:16 -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; Tue, 27 Nov 2007 00:14:08 +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.1) with ESMTP id lAR0DiaZ004816; Mon, 26 Nov 2007 19:13:44 -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 lAR0DirA003835; Mon, 26 Nov 2007 19:13:44 -0500 Received: from livre.oliva.athome.lsd.ic.unicamp.br (vpn-14-49.rdu.redhat.com [10.11.14.49]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAR0Dful016133; Mon, 26 Nov 2007 19:13:42 -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.13.8) with ESMTP id lAR0DdoQ020213; Mon, 26 Nov 2007 22:13:39 -0200 Received: (from aoliva@localhost) by livre.oliva.athome.lsd.ic.unicamp.br (8.14.2/8.13.5/Submit) id lAR0Dc2L020212; Mon, 26 Nov 2007 22:13:38 -0200 To: Michael Matz Cc: Robert Dewar , Richard Guenther , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC References: <84fc9c000711050327x74845c78ya18a3329fcf9e4d2@mail.gmail.com> <47331636.9010308@adacore.com> From: Alexandre Oliva Errors-To: aoliva@oliva.athome.lsd.ic.unicamp.br Date: Tue, 27 Nov 2007 03:48:00 -0000 In-Reply-To: (Michael Matz's message of "Mon\, 26 Nov 2007 17\:54\:33 +0100 \(CET\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00697.txt.bz2 On Nov 26, 2007, Michael Matz wrote: > Hi, > On Fri, 23 Nov 2007, Alexandre Oliva wrote: >> Yep. Nowhere does that bug report request parameters to be forced live. > Not in that bug report perhaps, but we got requests for exactly this, i.e. > to be able to introspect all parameters of all functions, be they inlined > or not, at all time. I think that's a reasonable request even (which in > some situations comes at a cost). Fair enough. And we agree this is not about debug info, it's about limiting optimizations, so this is indeed a different problem from the one I was asked to address. >> 2. function is inlined, the argument is unused and thus optimized >> away, but the function does some other useful computation >> >> At the inlined entry point, we have a note that binds the argument to >> its expected value. As we transform the program and optimize away the >> argument, we retain and update the note, > As far as possible. If it's not possible you loose (with our > requirements). If the argument is completely removed, yes, you won't be able to get to it by merely improving debug information. You actually have to change the generated code. >> If the value of a variable is completely optimized away at a point in >> the porogram, the correct representation for its location at that point >> is an empty set. > I think this is academic. If a value is dead, but happens to lie in a > place which isn't yet overwritten with something else, it is harmless to > reveal this value. It's the "last" value the variable had. If OTOH the > place _is_ already overwritten then it's important that we _don't_ say the > dead variable lies therein. Exactly. Full agreement. I wasn't talking about the *location* of the variable, or the variable itself. I was talking about the value. And I wrote "completely optimized away", not "dead". Liveness has very little to do with this issue. The only catch is that, once a variable should be *expected* to hold a different value, if debug information still claims the variable still holds the old value it shouldn't hold any more, just because the value happens to be around and the assignment of the new value could be optimized away, then I'd say debug information is incorrect. > So, for me correctness is defined a bit different than for you: > 1) if location L contains value X, then debug info should say so (as much > as possible, i.e. here the quality of the info comes into play) > 2) if location L does not contain value X, debug info should not say that > it does. This is the correctness part. Your definition is exactly what I've been trying to communicate. It looks like we're in complete agreement as to the goals and the two different metrics (1 being completeness, 2 being correctness). So either there's some other underlying difference or you'll soon realize that the simple SSA name<->variable mapping is insufficient to get you correctness. > Where we differ in opinion (I think) is, when location L doesn't contain > value X anymore. For you it's when X becomes dead. For me it's when X is > dead and when location L is overwritten (with something different than X). For me, it's when X is overwritten. That's the point at which the user is entitled to expect the variable to no longer hold its previous value (assuming they're different). Consider this program: int foo(int x) { int i; i = x; p1(); i++; p2(i); i++; p3(); } int main() { foo(1); } If you set a breakpoint in p1(), go up one frame and print i, you should ideally get 1 (although "unavailable" is always correct, even if undesirable). If you set a breakpoint in p2(int), you should get 2, but "unavailable" is quite likely in the presence of optimization, depending on the calling conventions. If you set a breakpoint in p3(), you should get 3, but "unavailable" is quite likely, given that the value is not even computed, and it's based on a value that is dead and thus may have been overwritten. Getting any other values at any of these points would be a bug in the compiler. Does this sound sound to you? Did you somehow get the impression that the SSA<->names mapping can get you correct results? >> Accuracy comes first. If we ever emit debug information saying 'this >> variable is here' for a point in the program in which it's in fact >> elsewhere > I agree here ... >> or unavailable, that's a bug to be fixed. > ... and disagree here. If a value is dead it's not necessarily > unavailable in my world. I never said "dead", you did. I said "unavailable", and by that I don't mean "dead", I really mean "unavailable". The value I'm talking about is not "whatever was last assigned to something that resembles the variable after numerous optimizations" but rather "a value the user might expect the variable to hold at that point in the program", given some user tolerance to reordering and other optimizations. One reason I use separate functions for the breakpoint locations is precisely because at those points users are entitled to expect the state of the program to be stable, i.e., there isn't a lot of reordering or other surprises that a compiler can introduce across function calls that are by themselves in a statement. Another reason is that I still don't have a good answer for breakpoint locations at other points in the program that are less stable across optimizations, and I can't quite describe what I think users are entitled to expect at such other points. But the infrastructure needed to bring great improvements even in this regard is being set in place by getting them correct at stable points such as function calls. That said, I'm putting some thought into getting better debug information in these less stable points, but making it completely unsurprising in spite of optimizations isn't the task I was assigned. Making it correct and far more complete is. -- 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}