This is the mail archive of the gcc-bugs@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]

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806



------- Comment #4 from zadeck at naturalbridge dot com  2009-01-02 00:38 -------
Subject: Re:  [ira] error in start_allocno_priorities,
 at ira-color.c:1806

2009-01-01  Kenneth Zadeck <zadeck@naturalbridge.com>

    PR rtl-optimization/35805
    * df-problems.c (df_lr_finalize): Add recursive call to resolve lr
    problem if fast dce is able to remove any instructions.
    * dce.c (dce_process_block): Fix dump message.

This patch fixes the problem.  The comment in the patch describes the
issue.    Since this was not really a failure, it would be hard to make
this issue into a testcase.

Ok to commit?

Bootstrapped and regression tested on x86*.

Kenny
Index: df-problems.c
===================================================================
--- df-problems.c       (revision 142954)
+++ df-problems.c       (working copy)
@@ -1001,22 +1001,32 @@ df_lr_transfer_function (int bb_index)
 /* Run the fast dce as a side effect of building LR.  */

 static void
-df_lr_finalize (bitmap all_blocks ATTRIBUTE_UNUSED)
+df_lr_finalize (bitmap all_blocks)
 {
   if (df->changeable_flags & DF_LR_RUN_DCE)
     {
       run_fast_df_dce ();
-      if (df_lr->problem_data && df_lr->solutions_dirty)
+
+      /* If dce deletes some instructions, we need to recompute the lr
+        solution before proceeding further.  The problem is that fast
+        dce is a pessimestic dataflow algorithm.  In the case where
+        it deletes a statement S inside of a loop, the uses inside of
+        S may not be deleted from the dataflow solution because they
+        were carried around the loop.  While it is conservatively
+        correct to leave these extra bits, the standards of df
+        require that we maintain the best possible (least fixed
+        point) solution.  The only way to do that is to redo the
+        iteration from the beginning.  See PR35805 for an
+        example.  */
+      if (df_lr->solutions_dirty)
        {
-         /* If we are here, then it is because we are both verifying
-         the solution and the dce changed the function.  In that case
-         the verification info built will be wrong.  So we leave the
-         dirty flag true so that the verifier will skip the checking
-         part and just clean up.*/
-         df_lr->solutions_dirty = true;
+         df_clear_flags (DF_LR_RUN_DCE);
+         df_lr_alloc (all_blocks);
+         df_lr_local_compute (all_blocks);
+         df_worklist_dataflow (df_lr, all_blocks, df->postorder,
df->n_blocks);
+         df_lr_finalize (all_blocks);
+         df_set_flags (DF_LR_RUN_DCE);
        }
-      else
-       df_lr->solutions_dirty = false;
     }
   else
     df_lr->solutions_dirty = false;
Index: dce.c
===================================================================
--- dce.c       (revision 142954)
+++ dce.c       (working copy)
@@ -601,7 +601,7 @@ dce_process_block (basic_block bb, bool

   if (dump_file)
     {
-      fprintf (dump_file, "processing block %d live out = ", bb->index);
+      fprintf (dump_file, "processing block %d lr out = ", bb->index);
       df_print_regset (dump_file, DF_LR_OUT (bb));
     }



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35805


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