Designs for better debug info in GCC

[Alexandre Oliva]

On Nov 26, 2007, Michael Matz <matz@suse.de> wrote:

> Hi,
> On Fri, 23 Nov 2007, Alexandre Oliva wrote:

>> On Nov 13, 2007, Michael Matz <matz@suse.de> wrote:
>> 
>> > The nice thing is, that there are only few places which really get rid of 
>> > SETs: remove_insn.  You have to tweak that to keep the information around, 
>> > not much else (though that claim remains to be proven :) ).
>> 
>> And then, you have to tweak everything else to keep the note that
>> replaced the set up to date as you further optimize the code.

> No.  remove_insn() would replace the SET with a note.

What information would this note convey?

> After all, there must have been a reason for the SET to be deleted:
> the destination is dead, hence whatever user-variables were
> associated with it also are dead.

Note quite.  The destination could be merely redundant.  And the
difference is crucial.

If you delete a copy (or some other redundant computation, you don't
seem to handle this case) that would install a value in a variable
that is available elsewhere, and then adjust the uses of the variable
such that they use the value elsewhere, you ought to note that the
variable holds that value, and at that point.

If you delete a computation because the result is completely unused,
then you ought to note that you no longer know the value of the
variable (or, ideally, that the variable would hold the result of that
computation if there was code to compute it).

In both cases, you ought to note that earlier values of the variable
are no longer current at that point.

In both cases, the notion of "at that point" is crucial, especially
when you deal with conditional assignments.  You don't want to make it
seem like a conditional assignment applies when the condition doesn't
hold.  Consider:

int foo(bool p, int x, int y) {
  int i = x;

  p1();

  if (p)
    i = y;

  p2();

  i++;

  p3(i);
}

int main() {
  foo (false, 3, 5);
}

At p1()'s caller's frame, you want i to hold the value 3.  At p2()'s,
you want i to still hold the value 3.  At p3(int)'s, it should be 4.

Now, if you change the program such that p is true, then at p1 i is
still 3, but at p2 it ought to be 5, and at p3(int)'s it should be 6.

How do you get that if you drop the assignments on the floor, or even
if you replace them assignments with notes that don't keep the correct
values associated not only with the names, but also with the points in
the program?

-- 
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}