inline

[Stephen Weeks]

> 1. SsaTree.Function.alphaRename is very simple; doesn't do formal
> substitution, just copies the function and renames all labels and
> variables.

This looks fine.

> 2. There is only one size heuristic; I did't understand why leaf and
> non-recursive used one and product used another.

No reason.  This looks good too.

> 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).

I checked in the necessary fixes to the backend.

> However, with the flattenCPS enabled, s-n-f falls into #4 with a "strange
> Offset" error. 

This now works as well.

> 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.

Maybe it makes sense to run introduce loops both before and after inlining.
It's cheap, so that should be OK.  I'm thinking of cases like even/odd, where
one of a pair of mutually recursive functions is inlined, creating a self-call.