Re: Designs for better debug info in GCC

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 12, 2007, Ian Lance Taylor <iant@google.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> 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}