| Message ID | 4E2A0E8A.9010700@redhat.com |
|---|---|
| State | New |
| Headers | show |
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.
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~
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.
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); }