Re: RFC: BB duplication code

[Jan Hubicka <jh at suse dot cz>]

> On Wed, Aug 22, 2001 at 09:27:56PM +0200, Jan Hubicka wrote:
> > But this has problem of tracking down instruction calculaitng the value.
> 
> Yep.  I have no good idea how so solve that.
Neighter I do - so lets avoid duplication for now.  I believe it is not
critical for the optimizations to be effective.
> 
> > Sane way is to strip them.  This works for superblock formation/loop peeling
> > as it usually don't want to duplicate whole loop.
> > But if I do, I lose the information.
> 
> I'd say strip the loop notes.  You don't really lose any information,
> in that correct information can always be obtained from the shape of
> the CFG, via flow_loop_nodes_find.
Agreed - anyway an loop optimizer is still an barrier for my effort.
Until it is converted to use CFG, we can't make flow info survive.

BB duplication framework can be usefull step in rewriting loop optimizer,
as loop unrolling can be definitly done at the top of it.
Converting whole loop optimizer at once can be huge task. Additionally some
pieces should be already obsoletted (as code hoisting).
So I think that in mid term, we can make the BIV/GIV discovery code idedendent
on loop notes (it should not be that dificult) and start work on new loop
unroller done as separate pass.
I was looking at some compiler designs and loop unrolling seems to be done
mostly at pretty late levels of compilation (as strength reduction is),
while other loop transformations are done early.

Do we have plans about the loop transformations done at tree level?
> 
> > LOOP notes are not problem as we should move away from them and
> > their absence does not harm, but what about BLOCK_BEG/BLOCK_END?
> 
> BLOCK_BEG/END must be properly duplicated for debug info to be correct.
I see.
> 
> > It is, but I need to understand how and see if it still works with presence
> > of duplicated BB - OK, I will try to investigate this futher.
> 
> It should.  The reorder_blocks (bad name) function is also used 
> for loop unrolling, which does duplication.  Additionally, when
> bb-reorder moves two blocks that shared a BLOCK_BEG/END, duplicates
> are created.
This means that when I am duplicating BB that starts BLOCK_BEG in the middle, I
can easilly add an paired BLOCK_END at the end of basic block and get info
correct?

(symetrically att BLOCK_BEG to the begginign of block if needed)?
> Careful, if the target uses a pc-relative load, there may be
> no such instruction.  Which is actually ideal for you.
I see there are many side corners :(

Honza