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.
