Re: RFC: BB duplication code

[Richard Henderson <rth at redhat dot com>]

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.

> 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.

> 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.

> 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.

> So open is tablejumps - I suggest go initialy by prohibiting duplication.

Seems good.

> Later we may want with some conservative way - in case we will find the
> instruciton taking CODE_LABEL of ADDR_VEC as argument we will allow
> duplication otherwise we won't.

Careful, if the target uses a pc-relative load, there may be
no such instruction.  Which is actually ideal for you.

The best way would be to search the dominator tree for the insn
that loads the label.  What to do when you find it is somewhat
complicated.  It's not impossible that the entire table index,
load, and decode could have been hoisted.

There are probably simple cases that can be handled easily, but
you'll probably always have to be able to cancel the duplication.


r~