Bug 43515 - Basic block re-ordering unconditionally disabled for Os
Summary: Basic block re-ordering unconditionally disabled for Os
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.4.1
: P3 enhancement
Target Milestone: 6.0
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2010-03-25 11:18 UTC by Rahul Kharche
Modified: 2016-10-26 08:08 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2010-03-26 12:24:22


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rahul Kharche 2010-03-25 11:18:46 UTC
Basic block re-ordering appears to be unconditionally disabled when optimizing for size, irrespective of whether -freorder-blocks was specified on command line. This is applicable to all versions 4.4.1 - 4.5.

As suggested in the following discussion this is incorrect behaviour
http://gcc.gnu.org/ml/gcc/2010-03/msg00365.html
Comment 1 Richard Biener 2010-03-26 11:49:58 UTC
It's disabled on a function-by-function basis which looks valid.
Comment 2 Steven Bosscher 2010-03-26 12:24:21 UTC
No, the user should be able to say "do this" and then the compiler should do so. Right now the flag to enable BB-reorder has no effect at -Os, and that is a bug.
Comment 3 Rahul Kharche 2010-03-26 12:25:23 UTC
The following test in 'rest_of_handle_reorder_blocks'

if ((flag_reorder_blocks || flag_reorder_blocks_and_partition)
     && optimize_function_for_speed_p (cfun))
{ ... }

suggests when optimize_size is true reordering would not run, even if I were to use -freorder-blocks as a command line option or a function attribute?

I also just noticed PR41396 is related.
Comment 4 Richard Biener 2010-03-26 13:01:38 UTC
Well, it's like you say -ftree-pre but a partial redundancy is not removed
because it was on a cold path.  bb-reorder should probably take into account
size/speed optimization in more general and the optimize_function_for_speed_p
predicate doesn't properly honor attribute(("hot")) with -Os, but I can't
see anything wrong with trying to optimize cold parts of a program for size
(and no, we do not have a flag to override this).
Comment 5 Andrew Pinski 2016-10-26 06:16:49 UTC
Hmm, I think this changed recently (within the last 2 years).
Comment 6 Andrew Pinski 2016-10-26 08:08:24 UTC
Fixed for GCC 6 by:

r228318 | segher | 2015-09-30 23:38:24 -0700 (Wed, 30 Sep 2015) | 23 lines

bb-reorder: Add -freorder-blocks-algorithm= and wire it up

This adds an -freorder-blocks-algorithm=[simple|stc] flag, with "simple"
as default.  For -O2 and up (except -Os) it is switched to "stc" instead.
Targets that never want STC can override this.  This changes -freorder-blocks
to be on at -O1 and up (was -O2 and up).

In effect, the changes are for -O1 (which now gets "simple" instead of
nothing), -Os (which now gets "simple" instead of "stc", since STC results
in much bigger code), and for targets that wish to never use STC (not in
this patch though).


2015-09-23   Segher Boessenkool  <segher@kernel.crashing.org>

        * bb-reorder.c (reorder_basic_blocks): Use the algorithm selected
        with flag_reorder_blocks_algorithm.
        * common.opt (freorder-blocks-algorithm=): New flag.
        (reorder_blocks_algorithm): New enum.
        * flag-types.h (reorder_blocks_algorithm): New enum.
        * opts.c (default_options_table): Use -freorder-blocks at -O1 and up,
        and -freorder-blocks-algorithm=stc at -O2 and up (not at -Os).