Re: RFC: BB duplication code

[Richard Henderson <rth at redhat dot com>]

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.

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

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

> 3) Can I update debug information using exiting bb-reorder infrastructure?
>    It seems to work already somehow.

Yes, that's already implemented.

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


r~