[patch] Preserve the CFG until after final

[Eric Botcazou]

> That is only partially true. Currently the transition is already de
> facto going on: Just look at how many back ends use
> compute_bb_for_insn to re-initialize the BLOCK_FOR_INSN pointers right
> after pass_free_cfg (it's usually the first thing they do in the
> machine-reorg pass).

Yes, and we should do something about it.  Btw, why is the line removed from 
ia64_reorg in the patch (and not mentioned in the ChangeLog)?

> Some ports never call free_bb_or_insn after that,
> and expect BLOCK_FOR_INSN to be valid in 'final'. One of those ports
> is i386, look at where BLOCK_FOR_INSN is used in i386.c (in functions
> deciding what asm output templates to use).

AFAICS it's only used for splitters.  And using BLOCK_FOR_INSN after the last 
split pass (pass_split_for_shorten_branches) is dubious.  Here's the list:

./frv/frv.c:               || BLOCK_FOR_INSN (insn) == ce_info->else_bb

Only used during if-conversion.

./rs6000/rs6000.c:  bb = BLOCK_FOR_INSN (label);

Only used during compute_alignments.

./spu/spu.c:  bitmap_set_bit (blocks, BLOCK_FOR_INSN (branch)->index);

Only used during md_reorg.

./c6x/c6x.c:  BLOCK_FOR_INSN (bundle) = BLOCK_FOR_INSN (slot[0]);

Only used during md_reorg.

./mips/mips.c:  basic_block bb = BLOCK_FOR_INSN (insn);
./mips/mips.c:  /* Restore the BLOCK_FOR_INSN pointers, which are needed by 
DF.  Also during

Only used for splitting decision, deal with null BLOCK_FOR_INSN.

./i386/i386.c:  basic_block bb = start ? BLOCK_FOR_INSN (start) : NULL;
./i386/i386.c:  basic_block bb = BLOCK_FOR_INSN (insn);
./i386/i386.c:  basic_block bb = start ? BLOCK_FOR_INSN (start) : NULL;
./i386/i386.c:  basic_block bb = BLOCK_FOR_INSN (insn);
./i386/i386.c:  basic_block bb = BLOCK_FOR_INSN (insn);
./i386/i386.c:  rtx start = BB_HEAD (BLOCK_FOR_INSN (insn));
./i386/i386.c:      basic_block bb =  BLOCK_FOR_INSN (insn);

Only used for splitting decision (and scheduling).

> Also, right now I'm stuck with a chicken-and-egg problem: dbr_schedule
> is not CFG-aware, but my still slowly progressing work on a
> replacement can't have a CFG because it has to run after machine-reorg
> passes, and therefore after pass_free_cfg.

That's why I'm suggesting to get rid of or modify pass_free_cfg so that the 
CFG is still usable up to the point where it is really destroyed.

> > I think that an incremental step would be to allow the machine reorg
> > pass to use the CFG, even if it doesn't maintain it.
> 
> That is the current state of things already.

No, as you noted earlier, because of pass_free_cfg.

> But I need this exactly for that reason: To remove that blocker! :-)

I don't think so.  The goal for now shouldn't be to "preserve the CFG until 
after final" since we know it isn't feasible in the short term, but rather to 
preserve the CFG as long as possible.

So what about doing the following instead:
 1. Remove pass_free_cfg from the pipeline,
 2. Remove compute_bb_for_insn from all the md_reorg passes that call it,
 3. (Optionally) Do pass_free_cfg from all the md_reorg passes that don't,
 4. Do pass_free_cfg at the beginning of pass_delay_slots,
 5. Do pass_free_cfg at the end of pass_split_for_shorten_branches,

-- 
Eric Botcazou