Predication during scheduling

[Bernd Schmidt <bernds at codesourcery dot com>]

This patch allows a backend to set a new scheduler flag, DO_PREDICATION,
which will make the haifa scheduler try to move insns across jumps by
predicating them. On C6X, the primary benefit is to fill jump delay slots.

There is a new type of dependency, REG_DEP_CONTROL, which is used where
possible for dependencies against jumps rather than REG_DEP_ANTI. It
represents a dependency that can be broken if the dependent insn is
predicated with a condition opposite to that of the jump. If only one
such dependency is left, it is marked as cancelled, and the pattern of
the insn is replaced by a conditional version. Care needs to be taken to
undo these changes when backtracking. Since the whole idea can be
thought of as a type of speculation, I've reused the TODO_SPEC field to
hold information about the predication status.

When generating REG_DEP_CONTROL deps, we ensure that the insn is also
made to depend on the producer of the condition (nothing is ever lost by
adding these extra dependencies, since a normal dependency against the
jump would obviously also ensure that the insn is scheduled after the
producer of the jump's condition).

This alone is not sufficient, however: we must also verify while
scheduling that the condition register is not clobbered before such a
predicated instruction. If we schedule an insn that clobbers the
condition reg, we must restore the old pattern of a predicated insn, and
de-cancel the dependency.

The patch was forward ported from 4.5; it replaces the NON_FLUSH_JUMP_P
mechanism that Jakub added in the meantime by a new pending_jumps list.
The two should be equivalent - we independently came to the conclusion
that something like this is necessary, but I think it's slightly clearer
with the extra list for jumps.

Bootstrapped and tested on ia64-linux (c, c++ as always - anything else
doesn't build on gcc60). This was slightly pointless as I forgot to set
the DO_PREDICATION bit for ia64, so the only value was to find a
sched-deps crash when using sel-sched. I'll probably rerun that. Also
tested on c6x-elf (some small fluctuations in libstdc++ tests which I've
also seen with other patches and which appear random - possibly timeouts).


Bernd

Attachment: schedcontrol0930.diff
Description: Text document