Tremendous performance regression in 1.1.2 -> mainline

[Mike Stump]

> To: Brad Lucier <lucier@math.purdue.edu>
> Date: Thu, 06 Apr 2000 13:21:45 -0400
> From: David Edelsohn <dje@watson.ibm.com>

> Part of the problem may be due to GCC not applying appropriate
> heuristics (or any heuristics) to determine when an optimization
> will be effective.

If you think of all the possible optimizations as a search space, and
realize that it is forever bigger than you can ever brut force, then
you realize that any search that is more than linear, needs a limiter.
The limiter is a practical matter, and kicks in after you have found
99% of everything that your going to find in the next 5 days of
compiler run time (or so).  Some people code the general algorithms,
without any attention to limiter and limiter design.  And everytime
they do, someone comes up with a test case, and some of the time, we
say don't do that (why do you need >50,000 lines in _one_ function?),
and some of those times (it's output from yacc, or output of a scheme
compiler) they come up with reasons, and we then put a limiter in.

The good news is that putting in limiters is a no-brainer (at least
compared to coming up with good algorithms in the first place).  We
should just recognize that doing this is part of the work that _does_
need doing, and do it.  If we put in algorithms that are n^2 or
better, then we should make an effort to put in a limiter, and try a
timing at the boundary that we come up with (>600 megs and more than 5
hours aren't going to win friends).  It would be nice if the
artificial limits on optimization were in a single nice place, so that
people that wanted to tweak them (they are arbitrary after all), could
play with them in isolation.

We have a few now, with more going in, as the software evolves.  Some
of them have switches, -finline-limit for example, (that's one I
helped put in :-)) some of them don't.  Some are in .h files, some in
the C code.  Would be nice to stylized them to make them easier to
find.