Hi Bernd,
The patch is OK to me. But do we need reorder_loops for the c6x backend ?
I mean we can set the do_reorder parameter to FALSE to save compile
time, since c6x backend only choose hw-doloops whose body contains only one
basic block.
Cheers,
Felix
>
> On 01/05/2014 05:10 PM, Teresa Johnson wrote:
> > On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt <ber...@codesourcery.com>
> wrote:
> >> I have a different patch which I'll submit next week after some more
> >> testing. The assert in cfgrtl is unnecessarily broad and really only
> >> needs to trigger if -freorder-blocks-and-partition; there's nothing
> >> wrong with entering cfglayout after normal bb-reorder.
> >
> > Currently -freorder-blocks-and-partition is the default for x86. I
> > assume that hw-doloop is not enabled for any i386 targets, which is
> > why we haven't seen this?
>
> Precisely.
>
> > And will this mean that -freorder-blocks-and-partition cannot be used
> > for the targets that use hw-doloop? If so, should
> > -freorder-blocks-and-partition be prevented with a warning for those
> > targets?
>
> If someone explicitly chooses that option we can turn off the reordering in
> hw-doloop. That should happen sufficiently rarely that it isn't a problem.
> That's
> what the patch below does - bootstraped on x86_64-linux, tested there and
> with bfin-elf. Ok?
>
> >> I've also tested that Blackfin still benefits from the hw-doloop
> >> reordering code and generates more hardware loops if it's enabled. So
> >> we want to be able to run it at -O2.
> >
> > I looked at hw-doloop briefly and since it seems to be doing some
> > manual bb reordering I guess it can't simply be moved before bbro. It
> > seems like a better long-term solution would be to make bbro
> > hw-doloop-aware as Felix suggested earlier.
>
> Maybe. It could be argued that the code in hw-doloop is relevant only for a
> small class of targets so it should only be enabled for them. In any case,
> that's
> not stage 3 material and two ports are broken...
>
>
> Bernd
