Re: [RFC] New SSA variable mapping infrastructure

["Richard Guenther" <richard.guenther@gmail.com>]

On 11/9/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Nov  8, 2007, "Richard Guenther" <richard.guenther@gmail.com> 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;

<bb 2>:
  l = function_that_returns_5 ();
  breakpoint0 ();
  __asm__ __volatile__(""::"X" l);
  k.6 = i * 10 E{ k };
  if (i < j)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  breakpoint1 ();
  k = k.6;
  goto <bb 5>;

<bb 4>:
  breakpoint2 ();
  k = 0;

<bb 5>:
  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.