RFC: Patch for switch elimination (PR 54742)
Wed Sep 3 21:22:00 GMT 2014
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.
More information about the Gcc-patches