final cfg build problems

[Jeffrey A Law <law at cygnus dot com>]

I was looking at some additional PA problems related to the code to
rebuild the cfg just before dbr_schedule and stumbled on some interesting
issues.

First, I think some ports (sh, arm/thumb, mips16?) use machdep_reorg to
place constant pools within certain ranges of particular instructions.  We
have to be careful not to muck up those placements when we call the cfg
builder since it can move blocks around.

Similarly we need to keep from moving stuff around on the PA port too.

On the PA an ADDR_VEC is actually a bunch of jump instructions.  We expose
this implementation detail in machdep_reorg so that we can fill the delay
slots of the jump instructions in the ADDR_VEC in reorg.c.

However, we are not allowed to change the order or number of insns from
the casesi until the end of the jump table.  ie we have

	blr %r26,%r0		/* pc = . + 8 + %r26 << 2 */
	nop			/* Delay slot of vectored branch */

	.begin_brtab		/* Marker for optimizing linker */

	b case1			/* Branch to case #1 */
	nop			/* Delay slot for branch to case #1 */

	b case2			/* Branch to case #2 */
	nop			/* Delay slot for branch to case #2 */
	... etc ...
	
	.end_brtab		/* Marker for optimizing linker */

The blr is a pc-rel branch, so it's offset relative to the start of the
branch table can not change.  Each entry in the branch table must consist
of precisely 2 instructions.

It appears that merge_blocks took the code at "case1" and copied it into the
jump table and re-vectored the b case1 somewhere else.

That resulted in something like this:

        blr %r26,%r0
        nop

	.begin_brtab		/* Marker for optimizing linker */

	some insn
	b case1			/* Branch to case #1 */
	another insn		/* Delay slot for branch to case #1 */

	b case2			/* Branch to case #2 */
	nop			/* Delay slot for branch to case #2 */
	... etc ...
	
	.end_brtab		/* Marker for optimizing linker */


Now the "case1" branch code is 3 instruction long, which causes extremely
bad things to happen.

One thought for dealing with these various problems is to not optimize the
cfg, delete dead code, etc etc when we rebuild the cfg.  Just build the
cfg, notes and quit.

Otherwise we're going to have to look for another way to deal with ports
that play around with the branching structure in machdep_reorg and assume
that no later pass is going to muck it up.

Other thoughts?

jeff