Re: BB reorder forced off for -Os

[Dave Hudson <gcc@blueteddy.net>]

On 23 Mar 2010, at 22:30, Steven Bosscher wrote:

> On Tue, Mar 23, 2010 at 7:05 PM, Ian Bolton <bolton@icerasemi.com> wrote:
>> Is there any reason why BB reorder has been disabled
>> in bb-reorder.c for -Os, such that you can't even
>> turn it on with -freorder-blocks?
> 
> No, you should have the option to turn it on if you wish to do so. If
> that is not possible, I consider this a bug. If you open a PR and
> assign it to me, I'll look into it.

We're not able to enable BB reordering with -Os.  The behaviour is hard-coded via this if statement in rest_of_handle_reorder_blocks():

  if ((flag_reorder_blocks || flag_reorder_blocks_and_partition)
      /* Don't reorder blocks when optimizing for size because extra jump insns may
	 be created; also barrier may create extra padding.

	 More correctly we should have a block reordering mode that tried to
	 minimize the combined size of all the jumps.  This would more or less
	 automatically remove extra jumps, but would also try to use more short
	 jumps instead of long jumps.  */
      && optimize_function_for_speed_p (cfun))
    {
      reorder_basic_blocks ();

If you comment out the "&& optimize_function_for_speed_p (cfun)" then BB reordering takes places as desired (although this isn't a solution obviously).

In a private message Ian indicated that this had a small impact for the ISA he's working with but a significant performance gain.  I tried the same thing with the ISA I work on (Ubicom32) and this change typically increased code sizes by between 0.1% and 0.3% but improved performance by anything from 0.8% to 3% so on balance this is definitely winning for most of our users (this for a couple of benchmarks, the Linux kernel, busybox and smbd).


Regards,
Dave