This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Designs for better debug info in GCC
On 12/19/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> On 12/19/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> > On Dec 18, 2007, "Daniel Berlin" <dberlin@dberlin.org> wrote:
> >
> > > Consider PRE alone,
> >
> > > If your debug statement strategy is "move debug statements when we
> > > insert code that is equivalent"
> >
> > Move? Debug statements don't move, in general. I'm not sure what you
> > have in mind, but I sense some disconnect here.
>
> OKay, so if you aren't going to move them, you have to erase them when
> you move statements around.
>
Besides this, how do you plan on handling the following situations
(both of which reassoc performs *right now*). These are the
relatively easy ones
Here is the easy one:
z_5 = a_3 + b_3
x_4 = z_5 + c_3
DEBUG(x, x_4)
Reassoc may transform this into:
z_5 = c_3 + b_3
x_4 = z_5 + a_3
DEBUG(x, x_4)
Now x has the wrong value.
At least in this case, you can tell which DEBUG statement to eliminate
easily (it is an immediate use of x_4)
It gets worse, however
c_3 = a_1 + b_2
z_5 = c_3 + d_9
x_4 = z_5 + e_10
DEBUG(x, x_4)
y_7 = x_4 + f_11
z_8 = y_7 + g_12
->
c_3 = a_1 + b_2
z_5 = c_3 + g_12
x_4 = z_5 + e_10
DEBUG(x, x_4)
y_7 = x_4 + f_11
z_8 = y_7 + d_9
x_4 now no longer represents the value of x, but we haven't directly
changed x_4, it's immediate users, or the statements that immediately
make up it's defining values.
How do you propose we figure out which DEBUG statements we may have
affected without doing all kinds of walks?
(This is of course, a more general problem of how do i find which
debug statements are reached by my transformation without doing linear
walks)