On Tue, Jan 7, 2014 at 8:07 AM, Bernd Schmidt <ber...@codesourcery.com> wrote: > 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?
Ok, looks good to me. > > >>> 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... Ok, that makes sense. Thanks, Teresa > > > Bernd > -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
