This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fill more delay slots in conditional returns
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Jeff Law <law at redhat dot com>
- Date: Fri, 05 Apr 2013 10:22:23 +0200
- Subject: Re: Fill more delay slots in conditional returns
- References: <1769120 dot Os7kk4Zj9I at polaris> <CABu31nNzRK6AW7--sDBgAzu4kP+9O-isVqHuddG2CTKNqDDdLA at mail dot gmail dot com> <CABu31nP336+06GqbNEuv7zK+VdO8E9xW1K9+AWZPN8ShaWh76w at mail dot gmail dot com>
> 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