Patchwork Fix pass_partition_blocks vs -O0

login
register
mail settings
Submitter Richard Henderson
Date July 22, 2011, 11:58 p.m.
Message ID <4E2A0E8A.9010700@redhat.com>
Download mbox | patch
Permalink /patch/106403/
State New
Headers show

Comments

Richard Henderson - July 22, 2011, 11:58 p.m.
Well, technically it's not "broken" yet.  It will be as soon as it starts
touching DF data, since this pass runs before pass_df_initialize_no_opt.

But the only real consumer of BB_PARTITION is pass_reorder_blocks.  And
that pass is already gated to only run if optimization is enabled.  So
really there's no point in running this pass without optimization.

Committed.


r~
* bb-reorder.c (gate_handle_partition_blocks): Honor optimize.
Michael Matz - July 25, 2011, 1:02 p.m.
Hi,

On Fri, 22 Jul 2011, Richard Henderson wrote:

> Well, technically it's not "broken" yet.  It will be as soon as it starts
> touching DF data, since this pass runs before pass_df_initialize_no_opt.
> 
> But the only real consumer of BB_PARTITION is pass_reorder_blocks.  And
> that pass is already gated to only run if optimization is enabled.  So
> really there's no point in running this pass without optimization.
> 
> Committed.

Why not simply move pass_df_initialize_no_opt earlier?  Introducing more 
checks on optimize instead of only relying on flag_xxx seems to go the 
wrong direction.


Ciao,
Michael.
Richard Henderson - July 25, 2011, 3:24 p.m.
On 07/25/2011 06:02 AM, Michael Matz wrote:
> Hi,
> 
> On Fri, 22 Jul 2011, Richard Henderson wrote:
> 
>> Well, technically it's not "broken" yet.  It will be as soon as it starts
>> touching DF data, since this pass runs before pass_df_initialize_no_opt.
>>
>> But the only real consumer of BB_PARTITION is pass_reorder_blocks.  And
>> that pass is already gated to only run if optimization is enabled.  So
>> really there's no point in running this pass without optimization.
>>
>> Committed.
> 
> Why not simply move pass_df_initialize_no_opt earlier?  Introducing more 
> checks on optimize instead of only relying on flag_xxx seems to go the 
> wrong direction.

Primarily because of pass_reorder_blocks not running.


r~
Michael Matz - July 25, 2011, 4 p.m.
Hi,

On Mon, 25 Jul 2011, Richard Henderson wrote:

> >> But the only real consumer of BB_PARTITION is pass_reorder_blocks.  
> >> And that pass is already gated to only run if optimization is 
> >> enabled.  So really there's no point in running this pass without 
> >> optimization.
> >>
> >> Committed.
> > 
> > Why not simply move pass_df_initialize_no_opt earlier?  Introducing 
> > more checks on optimize instead of only relying on flag_xxx seems to 
> > go the wrong direction.
> 
> Primarily because of pass_reorder_blocks not running.

Yeah, well, that just means pass_reorder_blocks also could do with a 
better gate (indeed it doesn't do much except a CFG cleanup when neither 
flag_reorder_blocks nor flag_reorder_blocks_and_partition is set).  
Granted there are currently > 320 tests for optimize, so we'll survive one 
more, it just felt wrong.


Ciao,
Michael.

Patch

diff --git a/gcc/bb-reorder.c b/gcc/bb-reorder.c
index fac5b29..763cbe5 100644
--- a/gcc/bb-reorder.c
+++ b/gcc/bb-reorder.c
@@ -2212,6 +2212,7 @@  gate_handle_partition_blocks (void)
      user defined section attributes.  Don't call it if either case
      arises.  */
   return (flag_reorder_blocks_and_partition
+          && optimize
 	  && !DECL_ONE_ONLY (current_function_decl)
 	  && !user_defined_section_attribute);
 }