Delay slot filling - what still matters, and what doesn't matter so much anymore?

[Joern Rennecke]

Quoting Steven Bosscher <stevenb.gcc@gmail.com>:

> Hello delay-slot target maintainers :-)

N.B., that also includes me as ARC maintainer.

> First of all: What is still important to handle?
>
> It's clear that the expectations in reorg.c are "anything goes" but
> modern RISCs (everything since the PA-8000, say) probably have some
> limitations on what is helpful to have, or not have, in a delay slot.

Actually, for several targets, annulled-true delay slots are really
'anything goes' including other instructions with delay slots.
These targets just have branch variants with and without delay slots,
and fill_eager_delay_slots in fact pessimizes the code.

> According to the comments in pa.h about MASK_JUMP_IN_DELAY, having
> jumps in delay slots of other jumps is one such thing: They don't
> bring benefit to the PA-8000 and they don't work with DWARF2 CFI. As
> far as I know, SPARC and MIPS don't allow jumps in delay slots, SH
> looks like it doesn't allow it either

That's only the GCC port, because you get ICEs when you try it.  It would
really be better if we could just tell reorg that an unfilled delay slot is
OK if the branch is not likely.

> Another thing I completely fail to grasp, is how the pipeline
> scheduler and delay slots interact. Doesn't dbr_schedule destroy all
> the good work schedule_insns has tried to do? If so, how much does
> that hurt on modern RISCs?

Indeed, that is a problem.
The SH actually makes some scheduler adjustments to have an extra insn
available to put in the delay slot.