Re: final cfg build problems

[Joern Rennecke <amylaar at cygnus dot co dot uk>]

> Is there a good reason why dbr_schedule has to run *after* machdep_reorg?

Yes.  On the SH, constant pools are also sometimes inserted in mid-block,
adding a jump around them.  The jump has a delay slot.
When a conditional branch is out of range, extra unconditional jumps are
inserted, which have an extra delay slot, too.  The conditional branch before
the jump is inverted, thus changing the delay slot available there, too.

What I'd like to see is a callback before a jump_insn is changed to check
that is permitted.  This could be a target macro with a default to permit
everything so it wouldn't bother maintainers of ports that don't need it.

This would also solve two present problems that the SH port has:

- The block_branch_redirect pattern in sh.md and the code in
  sh.c:machinde_dependent_reorg to generate it could be dropped.
  It is a kludge to prevent reorg from creating out-of-range branches.
- rorg sometimes grabs instructions from a condjumps target and puts
  them in the delay slot of the condjump.  This is not only seldom useful
  for the SH - what you gain on the branch-taken path you loose on the
  branch-not-taken path - but can cause constant tables to get out of range.