I want to resend this patch for consideration. I applied the patch to trunk and confirmed that it bootstraps and doesn't cause test regressions. Is this ok for trunk?
Thanks, Easwaran On Fri, Dec 7, 2012 at 12:01 PM, Easwaran Raman <era...@google.com> wrote: > It seems I need to reset the debug uses of a statement before moving > the statement itself. The attached patch starts from the leaf to root > of the tree to be reassociated and places them at the point where > their dependences will be met after reassociation. This bootstraps and > I am running the tests. Ok if there are no test failures? > > Thanks, > Easwaran > > 2012-12-07 Easwaran Raman <era...@google.com> > * tree-ssa-reassoc.c(find_insert_point): New function. > (insert_stmt_after): Likewise. > (get_def_stmt): Likewise. > (ensure_ops_are_available): Likewise. > (rewrite_expr_tree): Do not move statements beyond what is > necessary. Remove call to swap_ops_for_binary_stmt... > (reassociate_bb): ... and move it here. > (build_and_add_sum): Assign UIDs for new statements. > (linearize_expr): Likewise. > (do_reassoc): Renumber gimple statement UIDs. > > > > On Thu, Dec 6, 2012 at 1:10 AM, Richard Biener > <richard.guent...@gmail.com> wrote: >> On Tue, Nov 6, 2012 at 1:54 AM, Easwaran Raman <era...@google.com> wrote: >>> I am unable to figure out the right way to handle the debug >>> statements. What I tried was to find debug statements that use the SSA >>> name defined by the statement I moved (using SSA_NAME_IMM_USE_NODE) >>> and then moved them as well at the right place. Thus, if I have to >>> move t1 = a + b down (after the definition of 'd'), I also moved all >>> debug statements that use t1 after the new position of t1. That still >>> caused use-before-def problems in ssa_verify. I noticed that the debug >>> statements got modified behind the scenes causing these issues. Any >>> hints on what is the right way to handle the debug statements would be >>> very helpful. >> >> I think you cannot (and should not) move debug statements. Instead you >> have to invalidate them. Otherwise you'll introduce confusion as debug >> info cannot handle overlapping live ranges. >> >> But maybe Alex can clarify. >> >> Richard.
