Re: speeding up enable checking

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

  In message <200007231324.JAA02759@caip.rutgers.edu>you write:
  > However an *optimized* compile (-S -g -O2) of the example code still
  > takes over half an hour and consumes over 400Mb on my
  > i686-pc-linux-gnu -> powerpc-ibm-aix4.1.4.0 cross compile attempts.
  > 
  > (Note the code is the result of creating insn-extract.i on a
  > powerpc-ibm-aix4.1.4.0 RTL check bootstrap.  I've had to move the .i
  > code off of my AIX4 box and try cross compiles on an x86-linux system
  > instead for three reasons.  One is system resources, the AIX4 box runs
  > out of memory.  Two is speed, the AIX4 box would takes forever to
  > finish.  Third, profiling is currently totally broken in the ppc
  > backend.)
Well, you mean you can't hold 400+M in-core?  Jeez, what a lame little box
you have  :-)  For reference my old HP D390 compiles it in about 7 minutes
with optimization :-)  Of course it has 1.5G of memory.  Anyway....

The fundamental problems:

 120k insns
  30k expressions  *** This one is the key ***
  78k registers    *** And this one *** 
  11k edges
   7k basic blocks

Not surprisingly optimizing a function of this nature takes a lot of
memory -- probably more than you have in-core and you're paging/swapping
to death (which is probably why it is so sloooooow).

The bad news -- there aren't any significant memory leaks in gcse.  Everything
of any significant size is returned.

The good news, I did find two bitmaps that were not needed at all, killing
them got back ~30M and there are a couple that we can free up earlier than
the code currently does (though not early enough to reduce the peak usage),
but giving them back earlier can help paging/swapping behavior.

With those changes it manages to get through gcse in less than 400M.

[ What should really be done for gcse is use the blocking factor code 
  to reduce the number of expressions we optimize on any given run.  I
  don't have time to look at this, but you might be able to by using the
  code in delete_null_pointer_checks as a guide. ]

You might be able to improve this by squashing the register #s (it's
probably about 75% populated) and maybe the insn #s (not sure how
full it is).

Anyway, I've got other things I need to be looking at -- if you want to
investigate more, I recommend looking into the code to optimize hunks
of expressions instead of all of them in parallel -- or find a way to
simplify the RTL checking code :-)

jeff