On 23 Mar 2010, at 22:30, Steven Bosscher wrote:
> On Tue, Mar 23, 2010 at 7:05 PM, Ian Bolton <[email protected]> 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
