Fix pass_partition_blocks vs -O0

Fix pass_partition_blocks vs -O0

[Richard Henderson]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

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~

[-- Attachment #2: z --]
[-- Type: text/plain, Size: 500 bytes --]

        * bb-reorder.c (gate_handle_partition_blocks): Honor optimize.

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);
 }

Re: Fix pass_partition_blocks vs -O0

[Michael Matz]

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.

Re: Fix pass_partition_blocks vs -O0

[Richard Henderson]

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~

Re: Fix pass_partition_blocks vs -O0

[Michael Matz]

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.