This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Patch for switch elimination (PR 54742)
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Steve Ellcey <sellcey at mips dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, james dot greenhalgh at arm dot com
- Date: Wed, 03 Sep 2014 15:22:35 -0600
- Subject: Re: RFC: Patch for switch elimination (PR 54742)
- Authentication-results: sourceware.org; auth=none
- References: <1407865606 dot 2601 dot 74 dot camel at ubuntu-sellcey> <53EA5D74 dot 9020809 at redhat dot com> <47b32a49-298e-44f0-b84b-b8f664847a67 at email dot android dot com> <53EA7BD0 dot 1030901 at redhat dot com> <CAFiYyc2U6WSFw_Cy95q27mNkFpJJVeBL8ZvAvXkO-=UpiJB4ag at mail dot gmail dot com>
On 08/13/14 03:44, Richard Biener wrote:
I don't see that this pass should "scrog" a loop beyond repair. Btw,
the "proper" way of just fixing loops up (assuming that all loop
headers are still at their appropriate place) is to _just_ do
loops_set_state (LOOPS_NEED_FIXUP).
This pass can quite easily create new irreducible loops and non-nested
loops, the pass may take a previously well defined natural loop and make
it irreducible. When I worked on it, I didn't see any reasonable way to
update the loop structures.
But still this is in theory very bad as you cause important annotations
to be lost. If the loop is truly gone, ok, but if it just re-materializes
then you've done a bad job here. Consider the case where a
loop becomes a loop nest - you'd want to preserve the loop header
as the header of the outer loop (which you'd have to identify its
header in some way - dominator checks to the rescue!) and let
fixup discover the new inner loop.
While I'd love to be able to be able to update and DTRT here, I just
couldn't see a way to do it. And while I hate losing the loop structure
and missed-optimizations that it may lead to later, I judged the benefit
of removing the multi-way branch to be so beneficial that it outweighed
the losses elsewhere.
Yes, we may have little utility for dealing with the more complex
cases and I've been hesitant to enforce not dropping loops on the
floor an ICE (well, mainly because we can't even bootstrap with
such check ...), but in the end we should arrive there.
It'd certainly be nice. I really don't like the idea of dropping loops
on the floor. If we can get there, great, but I suspect you'll find its
harder than expected.
jeff