inline

[Matthew Fluet]

Mostly complete port of inlining from CPS to SSA.

Caveats:
1. SsaTree.Function.alphaRename is very simple; doesn't do formal
substitution, just copies the function and renames all labels and
variables.  For inlining, we introduce all these renamed blocks, a new
block that has the args of the renamed function and Goto's the start
block, and the original Call becomes a Goto to this new block.  Shrinker
should push the actuals down through the inlined function. 
2. There is only one size heuristic; I did't understand why leaf and
non-recursive used one and product used another.  Easy enough to introduce
a new size heuristic for product.  
3. Currently, because Goto's have non-zero size under the heurisitc and
because no shrinking eliminates redundant goto's, functions in general are
larger than they should be, so inlining isn't as effective. 
4. This combination of SSA passes is tickling the "constant switch test
bug" that was discussed on MLton in mid January, 2001.  The regressions:
array, word, and world5 assert with "ensurePointer" when compiled with G0,
and respectively fail with an overflow exception in backend, wrong answer
at runtime, and "strange Offset" in x86-translate when compiled with G1
(i.e., with MLton.debug = false).
5. smith-normal-form fails under the regression script, but I can't
reproduce it in isolation.

*******************************************************************************

Ignore #5; it's the IntInf/flattening problem.  I've been running
regressions with -drop-pass flattenCPS, confident that I'd remember why
s-n-f fails. (It's early, I haven't had any coffee yet. ;)   
However, with the flattenCPS enabled, s-n-f falls into #4 with a "strange
Offset" error. 


Question: why does inline run before introduce loops?  We can't inline any
functions with self-calls, so it would seem to make sense to eliminate
those self-tail calls first, making more small loops inlinable.