RFC: BB duplication code

[Jan Hubicka]

> On Wed, Aug 22, 2001 at 08:29:00PM +0200, Jan Hubicka wrote:
> > 1) In case of copying tablejumps, the vector remains shared.  This is not
> >    good idea except very latest passes of compilation, but making tablejump
> >    unshared is dificult task, as code computing destination address using
> >    the table can be hoisted outside.
> >    What to do?  Prohibit duplication of tablejumps?
> 
> In the case of JUMP_TABLES_IN_TEXT_SECTION, yes, you absolutely cannot
> share the table.  This is used by targets that use pc-relative addressing
> from the jump instruction to the table.  VAX is the most extreme example
> in that the entire table is an argument to the instruction.
> 
> Without JUMP_TABLES_IN_TEXT_SECTION, you might be able to get away with
> sharing the tables.  I don't have a good feel for what sort of problems
> you might encounter.
In case I do duplication soon, in order to form superblock and do subsequent
optimizations on each superblock differently, I eventually will want
to redirect jumptable in one of superblock (lets say by edge redirection)
and due to sharing I will redirect both jumptables.

IMO we should absolutely avoid shared jumptables during compilation and
possibly make them shared at final pass, if this turns out to be
common enought.

But this has problem of tracking down instruction calculaitng the value.
> 
> > 2) Pairable notes are splitted off - I should probably handle the
> >    paired notes inside single basic block by duplicating, but what to do
> >    with notes starting or ending in the BB?
> 
> Which ones?
Any of them. I can imagine, if I do have LOOP_BEG/LOOP_END pair, I can
easilly preserve it, but if the loop cosist of multiple basic blocks,
I will get LOOP_BEG in one instance and while duplicating the basic block
i don't know if the basic block holding LOOP_END will get duplicated too.

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.

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?
> 
> >    What about EH region notes?  Should I prohibit duplication if EH region
> >    starts or ends in the BB?
> 
> There are no NOTE_INSN_EH_REG_BE/END notes during optimization.  They
> only exist during initial rtl generation and during final assemble output.
Good for me :)
> 
> > 3) Can I update debug information using exiting bb-reorder infrastructure?
> >    It seems to work already somehow.
> 
> Yes, that's already implemented.
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.
> 
> > 4) What about epilogues - I should probably copy the frame_related flag,
> 
> The frame_related flag is never set for epilogues, only prologues.
> 
> > 	* bb-reorder.c (reorder_duplicate_bb): New function.
> 
> Not ok yet -- you'll have to figure out what to do about addr_vec.
> 
> > + 	      CALL_INSN_FUNCTION_USAGE (new) = copy_insn (CALL_INSN_FUNCTION_USAGE (insn));
> 
> Wrap.
> 
> > + 	  case CODE_LABEL:
> > + 	    /*new = emit_label (gen_label_rtx ());*/
> [...]
> > +       /*debug_rtx (new);*/
> 
> Debugging?
Oh yes - as commented, I didn't wanted to OKay it yet.
But it looks like there are fewer issues than I've expected.

So open is tablejumps - I suggest go initialy by prohibiting duplication.
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.

For now I will add predicate can_diplicate_bb_p that will check this condition
and fail in presense of tablejump.

Other problem is BLOCK_BEG and debug info.  I will try to investigate it
overnight.

Honza