This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA:] Fix PR 40086 - reorg.c again and again
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 18 May 2009 18:55:07 +0200
- Subject: Re: [RFA:] Fix PR 40086 - reorg.c again and again
- References: <200905141116.n4EBG7aj024085@ignucius.se.axis.com>
> In the trail for *this* PR 40086, I listed a couple of
> alternative solutions, but I went for the same fix as in PR
> optimization/15296. In the patch below, I changed just one
> next_active_insn to next_real insn, the one exposed by the
> regression in the PR. What I'd like to do is to change *all*
> calls to next_active_insn into next_real insn in reorg.c and
> resource.c (not completely correct; what I'd *really* like to do
> is to rewrite reorg.c, alas...)
I wonder whether this is not a common case though and, consequently, whether
this won't pessimize too much. Suppose the old USE comes from an insn moved
to the delay slot of the jump in a previous pass; computing the redundancy of
the next active insn while disregarding the USE in-betwenn is correct since
redundant_insn will take into account the insns in the delay slot, hence the
USE effectively. So, if the outcome is positive, it is correct to delete the
next active insn and then try with the following one, the only requirement
being to preserve the old USE.
Did you take a look at the impact on gcc.c-torture/compile at -O2 for example?
> Ok for trunk and all open branches?
Things are different on the trunk since I changed back the DF problem to LIVE
so I'm not sure we need to patch reorg.c everywhere.
--
Eric Botcazou