Re: Loop optimiser upgrade (Was RFC: BB duplication code)

[Jan Hubicka <jh at suse dot cz>]

> 
> Yes, I agree.  Each of these modules should be decoupled as much as
> possible to simplify the maintenance.
> 
> Maybe we should try the unthinkable and have a go at designing the
> interfaces first ;-)

Sounds like good idea.  I still do have dificulties in thinking how all
those parts we plan fits together.

I have quite clean plans about CFG infrastructure, but concerning the loop
optimizer my little mind still goes crazy.

Maybe you noticed that some bits are already in. For instance the BB pre-header
code you have can be rewriten to use redirect_edge_and_branch.  Simply split
the header first and then redirect loopback edge.  That will work even with
multiple header predecesors.

First thing that comes into mind is how to update the "loops" datastructure
after updating the CFG?  It is probably needed to do so while unrolling loops
or peeling, as the loop nest will force too many rebuilds otherwise.

Main problem I see is in the bitmaps used to hold nodes of the CFG. Lets take
example of simple preheader/sink creation pass.  Any creating of basic block
would need shifting all these bitmaps.  If we use consistently create_block
function (I plan to do so), we can probably shift the bitmaps there, but it
is ugly.

One alternative I see is to not represent the bitmap explicitly, instead maitain
dominance tree and use it to always construct the entries at fly. (that should
be possible easilly or not?)

Another solution can be to use DJ graphs, that can be less sensitive to such
a local updates.  What do you think?

OK, another issues later :)

Honza
> 
> Michael.