Re: One more global.c speedup

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

  In message <199911120340.WAA25241@polya.math.purdue.edu>you write:
  > 
  > I appled your patch to the November 6 mainline.  The top times are now:
[ ... ]

  > 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.
Thanks.  I expected an improvement, but now *that* much of an improvement. I'm
pleasantly surprised.

  > Perhaps now it's time to work on jump :-).
I know what's going on in delete_from_jump_chain.  It's pretty obvious.  We
For each jump, we have a list of other unconditional jumps which reach the
same label.  Those lists are long because of the kind of code you are writing.

jeff