RFC: Patch for switch elimination (PR 54742)

[Jeff Law]

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