> 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
>
On 23 Mar 2010, at 22:30, Steven Bosscher wrote:
> On Tue, Mar 23, 2010 at 7:05 PM, Ian Bolton 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
On Tue, Mar 23, 2010 at 7:05 PM, Ian Bolton 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
> From: Ian Bolton [mailto:bol...@icerasemi.com]
> > 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?
On Tue, Mar 23, 2010 at 12:21:05PM -0700, Paul Koning wrote:
> Does -Os mean "optimize even if it ma
l...@icerasemi.com]
> Sent: Tuesday, March 23, 2010 2:06 PM
> To: gcc@gcc.gnu.org
> Subject: BB reorder forced off for -Os
>
> 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?
>
&
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?
From what I've heard on this list in recent days,
BB reorder gives good performance wins such that
most people would still want it on even if it did
increase cod
