On 12/19/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > > 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.
Yes. > > 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. Either that, or you would have to hunt all the uses of every single thing in the chain to see if any were debug expressions, and if the value is going to change. > > Is that the jist of it? Yes > > Andrew >
