benchmarks for the release

[Matthew Fluet]

> I'm confused why we are still outputting calls to empty functions.  At the
> least I would think a trivial peep-hole would fix this.

After the SSA optimizations, nothing in the backend or codegens are
interprocedural.  So, if you have a call to an SSA function at the end of
the SSA optimzations, it will appear in the executable.

The issue with md5 is that we have no metric (or even heuristic)  for
determining SSA optimizations to apply.  We simply run through the set of
optimizations and finish.  With md5, the last removeUnused pass determines
that the results of these SSA functions aren't used; between removeUnused
and the shrinker, the functions are reduced to "nothing."  But, we're at
the end of the SSA passes, so nothing inlines or eliminates these
functions.

Fundamentally, its the classic optimizing compiler problem -- for any set
of optimizations, I can always come up with a program that, after running
through your optimizations, can be further optimized.  md5 happens to be
one of those programs for our set of optimizations.  And, its even more
annoying because the "next" optimization is so obvious.  

Here were some thoughts we had from Jan. 4 2002:

> > > > I think that just eliminating those extraneous non-tail calls sped it up
> > > quite a bid.
> > > 
> > > Cool.  Maybe what we need is some count of how many opts the last
> > > shrink did, and if there werw a lot done, we re-run the simplifier.
> > 
> > Not quite sure what you mean here -- rerun the whole set of simplifier
> > passes?  Another option might be a fast set of passes that could be
> > repeatedly applied according to some heuristics.  Mostly to take care of
> > the "obvious cases" like the above -- if there are any really really small
> > functions, run the inliner.
> 
> Sounds good.  With the exception of inlining, I think all of the
> passes are guaranteed to not increase the size of the program.  Hence,
> it might make sense to run to fixed-point with a more conservative
> inliner.

This last comment is not entirely correct anymore; localRef and knownCase
have the potential to increase the size of the program.  Not so much from
their specific optimizations, but restoring the SSA conditions might mean
adding new arguments to blocks to thread variables through.