On 12/19/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > > On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> 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)
