Out-of-sight compile times for calculate_loop_depth

[Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>]

Brad Lucier writes:

 > http://www.math.purdue.edu/~lucier/_meroon.i.gz

Is this some machine generated program?  I guess it has lots of loops
with a large number of edges in the CFG from looking at the profiling
info.  I'll grab it later on when I've got a spare minute.

 > All routines with more than 5% runtime are:
 > 
 > Each sample counts as 0.000976562 seconds.
 >   %   cumulative   self              self     total           
 >  time   seconds   seconds    calls  ms/call  ms/call  name    
 >  36.66    104.63   104.63    59615     1.76     1.76  sbitmap_intersection_of_preds
 >  21.87    167.07    62.44 21551141     0.00     0.00  sbitmap_a_subset_b_p
 >   6.41    185.37    18.30     6596     2.77     2.77  flow_loop_exits_find
 >   5.15    200.08    14.71     6596     2.23     2.23  flow_loop_pre_header_find


This testcase exposes problems with the dominator calculation
algorithm and with flow_loop_node_add.  The latter I never
particularly liked since it can exhibit quadratic behaviour.  As an
interim solution, adding the loops to the loop tree in reverse order
should reduce the insertion time.

Michael.