Designs for better debug info in GCC
Andrew MacLeod
amacleod@redhat.com
Wed Dec 19 20:00:00 GMT 2007
> 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.
>
>
This does seem more troublesome. Reassociation shuffles things around
without changing the LHS presumably because it has looked at the uses
and knows there are no uses outside the expression, so it can manipulate
them however it wants. It elects not to create new temps since it knows
the old ones aren't being used elsewhere, so why wast new entries.
So if it was aware of the debug stmt, there would be a use of x_4
outside the expression, and it would no longer do the same reassociation.
Is that the jist of it?
Andrew
More information about the Gcc
mailing list