RFC: target-specific overrides to block reordering heuristics

[DJ Delorie <dj at redhat dot com>]

A little background: We've got this internal port that has
low-overhead looping opcodes, but for this port, the opcode goes at
the beginning of the loop, much like the c4x, but unlike the c4x we
can't always replace the loop opcodes with regular opcodes if the
circumstances no longer allow them.  Unfortunately, block reordering
makes the looping opcodes not work.  -fno-reorder-blocks fixes it, but
is not a good permanent solution.

So, what we had been doing is adding code to the backend to "undo" the
reordering that bb-reorder does, but it's very prone to error and
often breaks when bb-reorder breaks.  It was a bad solution.

So, what we'd like to do is figure out some way to tell bb-reorder
that certain chains of bbs must remain in the sequence they start in.
For example, if a doloop_begin is in bb 14, and the matching
doloop_end is in bb 18, then blocks 14..18 must remain in that order
in the final output.

So before I delve into this, I'd like to ask if anyone has an opinion
on this, like where the abstraction should be, how to implement, or if
it's just a totally bad idea in the first place (well, hopefully not
that one ;).

So far, I'm thinking that the target can define a hook of some sort,
to which bb-reorder passes an array of ints (one slot for each bb).
The target can fill in each slot with the bb of the start of the
chain, if a chain needs to be preserved, or leave the slot unchanged
if it can be reordered.