More degenerate flow graphs breaking if_convert.

[Richard Earnshaw]

Richard,

Remember that you checked in the following to fix a degenerate flow graph 
problem that caused if_convert to get lost?

	2000-05-15  Richard Henderson  <rth@cygnus.com>
        * toplev.c (rest_of_compilation): Run full jump pass before
        find_basic_blocks of flow2.

Well, I've now found a case where this is still insufficient.

gcc.c-torture/compile/20000326-1.c contains a completely degenerate switch 
statement, but since the switch is expanded into a set of compare-and-jump 
statements, we get the following after global_alloc has completed:

[bb 1]
J51:	pc := gt(cc, 0) ? L62 : pc

[bb 2]
I53:	r3 := #0x89abcdef

I54:	cc := cmp(r2, r3)

J55:	pc := eq(cc, 0) ? L72 : pc

[bb 3]
J60:	pc := L72

[bb 4]
L62:

The jump pass then merges bb's 2 & 3 to give

[bb 1]
J51:	pc := gt(cc, 0) ? L62 : pc

[bb 2]
I53:	r3 := #0x89abcdef

I54:	cc := cmp(r2, r3)

J60:	pc := L72

[bb 3]
L62:

The life_analysis pass then notes that I53 & I54 are both dead, so it 
deletes them.  This leaves us with:

[bb 1]
J51:	pc := gt(cc, 0) ? L62 : pc

[bb 2]
J60:	pc := L72

[bb 3]
L62:

Which, of course, is another degenerate jump block.  If_convert then gets 
confused just as before, since it doesn't know how to handle this case.

Unless we are going to keep re-running jump and life-analysis 
optimizations until nothing further changes, I don't see how we can 
prevent the above from recurring somehow.  This sort of implies that we 
have to have some defence against if_convert being given a degenerate flow 
graph.

This is with the same condition arm patches that I posted previously.  
Compilation was with -O1

R.