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