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
