From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14088 invoked by alias); 9 Nov 2007 09:53:19 -0000 Received: (qmail 14080 invoked by uid 22791); 9 Nov 2007 09:53:18 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.176) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Nov 2007 09:53:13 +0000 Received: by py-out-1112.google.com with SMTP id a29so1085384pyi for ; Fri, 09 Nov 2007 01:53:11 -0800 (PST) Received: by 10.65.83.18 with SMTP id k18mr6713623qbl.1194601991129; Fri, 09 Nov 2007 01:53:11 -0800 (PST) Received: by 10.65.232.20 with HTTP; Fri, 9 Nov 2007 01:53:11 -0800 (PST) Message-ID: <84fc9c000711090153m32ec85fo760209f1a5375603@mail.gmail.com> Date: Fri, 09 Nov 2007 11:55:00 -0000 From: "Richard Guenther" To: "Alexandre Oliva" Subject: Re: [RFC] New SSA variable mapping infrastructure Cc: "GCC Patches" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <84fc9c000710031126h26263c21yc30e9defa7bc6468@mail.gmail.com> <84fc9c000711070234u717269d5g9dbfc778be8d6fc3@mail.gmail.com> <84fc9c000711080125x36d4cfcdne5bd2358408ed055@mail.gmail.com> <84fc9c000711081225n209265f4n826d20fbd580972a@mail.gmail.com> X-IsSubscribed: yes 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-11/txt/msg00512.txt.bz2 On 11/9/07, Alexandre Oliva wrote: > On Nov 8, 2007, "Richard Guenther" wrote: > > > It would be nice to have a gdb testcase testing for not having this > > wrong debug information - at least that would make it easier to > > understand your point. > > Consider this: > > int foo(int i, int j) { > int l; > int k = 0; > > l = function_that_returns_5 (); > breakpoint0 (); > asm ("" : : "X" (l)); /* ensure it's live */ > > l = j + i * 10; > > if (i < j) { > k = i * 10; > breakpoint1(); > } else > breakpoint2(); > } > > breakpoint3(); > > return l + k; > } > > Set a breakpoint in all 3 breakpoint functions and, when you reach > them, go up one frame and print k and l. > > With your design, the optimizations that completely drop the second > assignment to l, leaving nothing behind to mark the death of the > previous value, debug information will likely indicate that variable l > still holds value 5 through to the end of the function, unless the > location holding it is reused for some other purpose, the only case in > which current var-tracking would realize l is no longer available > there. Right. As optimization drops the second assignment to 'l' we only are able to note that at the point we return from the function 'l' is computed again: foo (i, j) { int k.6; int k; int l; : l = function_that_returns_5 (); breakpoint0 (); __asm__ __volatile__(""::"X" l); k.6 = i * 10 E{ k }; if (i < j) goto ; else goto ; : breakpoint1 (); k = k.6; goto ; : breakpoint2 (); k = 0; : breakpoint3 (); return (j + k.6 E{ l }) + k; } And you are right, with our design-proposal there is no way to say that at the point of the second assignment to 'l' (even if that is removed), the name 'l' shall be no longer associated with the constant '5'. So indeed, it is very likely that in the debugger you would be able to print 'l' and get 5 at all breakpoint locations. 'k' will also print as i * 10 at at least breakpoint1() and breakpoint2() (it will be "correct" at breakpoint3()). Basically the constraints we can force on debug information is only that at the point of a use of a name the location information will be correct. I also don't see how you can solve this problem without retaining placeholders for each DCEd instruction (which is what you do). So yes, your approach is vastly superior in the sense of creating correct debug information for optimized code. What our approach basically does is to identify all names that a computed value has at any point during program execution. All flow-sensitive information that is not tracked we hope to recover (I see it's not possible to recover all of it). So we're obviously going to finish our approach to a point where you can try it (that is, run gdb sessions on the improved output) and then put it on a branch. Richard.