This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Designs for better debug info in GCC


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]