[Patch, bfin/c6x] Fix ICE for backends that rely on reorder_loops.
Wed Jan 8 19:41:00 GMT 2014
On Tue, Jan 7, 2014 at 8:07 AM, Bernd Schmidt <email@example.com> wrote:
> On 01/05/2014 05:10 PM, Teresa Johnson wrote:
>> On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt <firstname.lastname@example.org>
>>> 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
>>> 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?
>> 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
> 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
>>> 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
Teresa Johnson | Software Engineer | email@example.com | 408-460-2413
More information about the Gcc-patches