This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Scheduler questions (related to PR17808)
- From: Richard Earnshaw <rearnsha at gcc dot gnu dot org>
- To: Steven Bosscher <stevenb at suse dot de>
- Cc: Vladimir Makarov <vmakarov at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 30 Jun 2005 10:32:20 +0100
- Subject: Re: Scheduler questions (related to PR17808)
- References: <200506300046.22545.stevenb@suse.de>
On Wed, 2005-06-29 at 23:46, Steven Bosscher wrote:
> Hi,
>
> I have a question about the scheduler. Forgive me if I'm totally
> missing the point here, this scheduling business is not my thing ;-)
>
> Consider the following snippet that I've derived from PR17808 with a
> few hacks in the compiler to renumber insns and dump RTL with all the
> dependencies before scheduling.
[...]
>
> Notice how the conditional sets of r14 and r17 in insns 9 and 10 have
> been moved past insn 14, which uses these registers. Shouldn't there
> be true dependencies on insns 9 and 10 for insn 14?
Hmm, certainly looks suspicious, but it's not really what the original
bug report was about. This might be some interblock scheduling problem
that is also triggered by the extra scheduling freedom we get with the
disabled change.
The original problem was one where a BB with 2 output edges could have a
non-branch insn as the final instruction. This can't happen with
non-predicated machines, but when you have predicated insns the
execution path that leads to the non-fallthrough edge may not need to
suppress all the non-executed insns - we can just move them after the
branch. Unfortunately, later passes can't handle this (they expect a BB
with multiple exit edges to have a branch as the final insn.
I think the way to handle that is to push the 'left-over' insns onto the
fall-through edge and then create a new BB for them. If there is no
code label after the fall-through, then the new BB can be coalesced with
the fall-through block, otherwise it will become a new BB in its own
right. It might even be possible to remove the predication on the
instructions if they all use the same predicate register and the
condition is the inverse of the branch condition.
R.