This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Preserve the CFG until after final


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]