This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Preserve the CFG until after final
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 21 May 2013 16:14:36 +0200
- Subject: Re: [patch] Preserve the CFG until after final
- References: <CABu31nP2zmye87o-mrbJkKQnm0hPQyE8Pu88Bd3z3_1rOtAT0Q at mail dot gmail dot com> <1863188 dot IfdytJWQvO at polaris>
On Tue, May 21, 2013 at 10:57 AM, Eric Botcazou wrote:
>> This patch allows targets to keep the CFG around until after final, by
>> skipping pass_free_cfg and CFG-destructive passes like dbr_schedule,
>> and by making insn splitting before 'final' use split_all_insns
>> instead of split_all_insns_noflow if pass_free_cfg was skipped.
>
> Well, you currently can't skip dbr_schedule if you have delay slots, c6x set
> aside, so I'm not sure whether we want to start another transition before even
> knowing if we can reasonably complete it.
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). 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).
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.
>> For the moment, only ix86 uses the CFG-aware version of the hook, but
>> there are a handful of targets that can be converted to do this also
>> (ia64, bfin, c6x, sparc, probably others).
>
> Not SPARC for sure.
Right, SPARC doesn't have a machine-reorg pass anymore. I was talking
about pass_work_around_errata, that runs after my CFG-aware
dbr_schedule, properly maintaining the CFG.
>> I hope that maintainers will over time change their machine reorgs to
>> maintain the CFG, so that passes like pass_dwarf2_frame can use the
>> CFG instead of creating "a facsimile of one on the fly" (see
>> dwarf2cfi.c).
>
> 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.
> For the rest I'm not sure, as
> long as we have the dbr_schedule blocker.
But I need this exactly for that reason: To remove that blocker! :-)
Ciao!
Steven