Re: One more global.c speedup

[Brad Lucier <lucier at math dot purdue dot edu>]

> Brad, could you run your testcase through the compiler after applying this
> patch -- the single biggest hog according to your last -O profiling dump is
> record_conflicts.  I'd be interested to know if it makes any significant
> difference.

I appled your patch to the November 6 mainline.  The top times are now:

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
  8.01      8.99     8.99    30909     0.29     0.29  delete_from_jump_chain
  5.68     15.36     6.37        8   796.39  5305.31  jump_optimize_1
  5.24     21.24     5.88 10448965     0.00     0.00  rtx_renumbered_equal_p
  4.47     26.26     5.02  9164467     0.00     0.00  find_cross_jump
  3.93     30.68     4.41 16835940     0.00     0.00  next_active_insn
  3.73     34.86     4.18    93299     0.04     0.04  make_edge
  3.57     38.86     4.00   194464     0.02     0.02  record_one_conflict
  2.31     41.46     2.60        1  2596.68 111652.24  yyparse
...
  0.00    111.91     0.00    26627     0.00     0.00  record_conflicts

With your patch, record_conflicts is a no longer an issue. And it cut
the time for global-alloc in half (these times are for the unprofiled
cc1):

time in parse: 15.013808 (11%)
time in jump: 64.724416 (48%)
time in cse: 5.631520 (4%)
time in loop: 0.050752 (0%)
time in flow: 6.789056 (5%)
time in combine: 6.199552 (5%)
time in local-alloc: 3.100752 (2%)
time in global-alloc: 15.866832 (12%)
time in flow2: 5.433392 (4%)
time in shorten-branch: 0.420656 (0%)
time in final: 4.006480 (3%)
time in varconst: 0.001952 (0%)
time in gc: 1.885632 (1%)

So in a week, the time for global-alloc was cut from 883 seconds to
< 16 seconds on this test.  Almost unbelievable.

Perhaps now it's time to work on jump :-).

Brad