try_crossjump_bb and computed gotos

[Brad Lucier]

Dan Berlin send me a very small patch to recog.c that fixes one of
my big timing problems with cc1, which is quite cool.  I presume
he'll submit it for checkin soon.

After that patch is checked in, there is no real glaring single time
hog in cc1 on my tests, but both try_crossjump_bb and try_forward_edges
take a fair amount of time---from the profiled run data:

-----------------------------------------------
                0.03   34.31       3/22          update_life_info [13]
                0.20  217.28      19/22          cleanup_cfg [9]
[10]    23.4    0.23  251.59      22         try_optimize_cfg [10]
               91.07   98.28  109402/109402      try_crossjump_bb [11]
               54.39    0.15  258064/258064      try_forward_edges [17]
                2.05    2.62    5781/8152        flow_delete_block [52]
                0.12    1.98  258064/258064      try_simplify_condjump [95]
                0.00    0.37    1349/1349        merge_blocks [216]
                0.03    0.28   72957/82221       redirect_edge_and_branch [223]
                0.00    0.18    1560/18777       flow_delete_insn_chain [92]
                0.01    0.03  116795/103995467     forwarder_block_p [28]
                0.01    0.01   82897/62438905     onlyjump_p [41]
                0.01    0.00     368/11221       redirect_edge_succ [222]
                0.00    0.00    1560/262677      reg_mentioned_p [400]
                0.00    0.00     368/10071       redirect_edge_succ_nodup [784]
-----------------------------------------------

I understand the principle of what try_crossjump_bb is trying to do,
if not the details.  I'm wondering if there is a early exit that it
could take in the presence of critical or abnormal edges; try_crossjump_bb checks
for complex edges, but not for critical or abnormal ones.

Brad Lucier