This is the mail archive of the gcc-patches@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: [Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806


Kenneth Zadeck wrote:
> Steven Bosscher wrote:
>   
>> On Fri, Jan 2, 2009 at 7:37 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
>>   
>>     
>>>>> At this point, if your patch costs say 0.3%, and removing all traces
>>>>> DF_LR_RUN_DCE (instead scheduling a dozen more pass_fast_rtl_dce in
>>>>> passes.c) costs 0.5%, I'd rather see the latter, at least it's easier to
>>>>> look for opportunities to remove some useless DCE.
>>>>>         
>>>>>           
>>> I'll try to do this for 4.5.
>>>     
>>>       
>> It might be more worthwhile to just "fix" IRA to use DF_LIVE (which
>> Vlad should have done in the first place). Then we wouldn't need
>> Kenny's patch and DF_LR_RUN_DCE would still be essentially free.
>>
>> Gr.
>> Steven
>>     
> There is the issue of correctness vs rot.   I actually think that one of
> the reasons that flow was so bad was that people went down this long
> slippery slope of well it is good enough here ... and we really can get
> away with it not being right here ... and after a while, all you have is
> garbage.
>
> The problem with this game is that it is not maintainable.   Those kinds
> of decisions tend to get forgotten and lost as the personnel supporting
> the compiler changes.    Even if it is a fractional percentage slower,
> the fact that you do not have to reason about it as the compiler evolves
> is actually quite important.  
>
> Thus, I plan to both fix this bug and add another one for vlad to fix
> the sets that he uses. 
>
> Kenny
>   
2009-01-02  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.
   
Rebootstrapped and regression tested on x86*.

Committed as revision 143027.

Kenny
Index: ChangeLog
===================================================================
--- ChangeLog	(revision 142954)
+++ ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+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.
+	
 2008-12-29  Seongbae Park  <seongbae.park@gmail.com>
 
 	* tree-profile.c (tree_init_ic_make_global_vars): Make static
Index: df-problems.c
===================================================================
--- df-problems.c	(revision 142954)
+++ df-problems.c	(working copy)
@@ -1001,25 +1001,34 @@ 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)
 {
+  df_lr->solutions_dirty = false;
   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));
     }
 

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