> Thinking about this some more: This could be fixed by inserting a > machine-specific pass just after delayed-branch scheduling, like in > the attached patch. I think the same is possible with the dbr_schedule > call in the MIPS backend. > > Eric, what do you think of this approach?
No objections on principle from a SPARC viewpoint. But can we really control when the pass is run with register_pass? Because it needs to be run _before_ branch shortening. > With those two dbr_schedule calls out of the way, it will be a lot > easier to change things such that pass_free_cfg can run after > pass_machine_reorg (and after pass_cleanup_barriers that can be > simplified if there's still a CFG around). It will also help make the > DELAY_SLOTS hack in cfgrtl.c:rest_of_pass_free_cfg redundant. I agree that we should get rid of MIPS/SPARC's dbr_schedule shuffling. -- Eric Botcazou
