From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2729 invoked by alias); 23 Nov 2007 23:40:13 -0000 Received: (qmail 2698 invoked by uid 22791); 23 Nov 2007 23:40:11 -0000 X-Spam-Check-By: sourceware.org Received: from lsd-gw.ic.unicamp.br (HELO marquesa.lsd.ic.unicamp.br) (143.106.7.165) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Nov 2007 23:40:00 +0000 Received: from freie.oliva.athome.lsd.ic.unicamp.br (gw-to-emilia.oliva.athome.lsd.ic.unicamp.br [172.31.160.17] (may be forged)) by marquesa.lsd.ic.unicamp.br (8.14.1/8.14.1) with ESMTP id lANNdoUS028380; Fri, 23 Nov 2007 21:39:50 -0200 Received: from livre.oliva.athome.lsd.ic.unicamp.br (livre.oliva.athome.lsd.ic.unicamp.br [172.31.160.2]) by freie.oliva.athome.lsd.ic.unicamp.br (8.14.1/8.14.1) with ESMTP id lANNdmCJ005004; Fri, 23 Nov 2007 21:39:48 -0200 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 lANNdlge025744; Fri, 23 Nov 2007 21:39:47 -0200 Received: (from aoliva@localhost) by livre.oliva.athome.lsd.ic.unicamp.br (8.14.2/8.13.5/Submit) id lANNdlJ8025743; Fri, 23 Nov 2007 21:39:47 -0200 To: Ian Lance Taylor Cc: Mark Mitchell , 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> <4732519C.6070802@codesourcery.com> <4733554D.4040402@codesourcery.com> <4737BBBF.3080400@codesourcery.com> From: Alexandre Oliva Errors-To: aoliva@lsd.ic.unicamp.br Date: Sat, 24 Nov 2007 01:44:00 -0000 In-Reply-To: (Ian Lance Taylor's message of "12 Nov 2007 10\:09\:10 -0800") 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/msg00595.txt.bz2 On Nov 12, 2007, Ian Lance Taylor wrote: > Alexandre Oliva writes: >> And then, optimizations move instructions around, but I don't think >> they should move the assignment notes around, for they should >> reflect the structure of the source program, rather than the >> mangled representation that the optimizers turn it into. > I'm not sure I follow this. If the equivalent of some source code > line is hoisted out of a loop, shouldn't the user variable assignments > follow it? Why should it? The user is entitled to expect the variable to be set to that value at the right point in the program, no earlier than that. Before the assignment point in the program, we ought to note that the variable holds its previous value, or that its previous value is no longer available. But noting it holds a value it should only hold at a later point doesn't seem right to me. Consider, again, the example: f(int x, int y) { int c; c = x; do_something_with_c(); c = y; do_something_with_c(); } If we optimize away the assignments c=x and c=y, and just use x and y instead (assume c is not otherwise modified), what should we note in debug info? Should we pretend that c is dead all over, just because it was optimized away? Should we note that it's live in both x and y registers/stack slots? Or should we vary its location between x and y, at the assignment points, as expected by the user? Now, what if f() is inlined into a loop, such that c could be versioned and the assignments to it could be hoisted, because x and y don't vary? Should this then change the debug information generated for variable c from the IMHO correct points to the loop entry points? > After the scheduler has run over a large basic block, the > structure of the source program is gone. The mapping becomes more difficult, yes. But the structure of the source program remains untouched, in the source program. And debug information is about mapping source concepts to implementation concepts. So we should try to map source concepts that remain in the implementation to the remaining implementation concepts. > Side note: I think it would be unwise to discuss specific patents on > this public mailing list. I think that where we have specific patent > concerns, the steering committee should raise them on a telephone call > with the FSF and/or the SFLC. If you have concerns about a specific > patent, I recommend that you telephone some member of the SC, or send > e-mail directly to that person. That makes sense. I hadn't actually seen that patent before the day I mentioned it, and I still haven't got 'round to reading it. I just thought it would be wise to inform people about the danger of going down that path, but now I realize it may not have been wise at all. Sorry for not thinking about it. -- 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}