new coalescer on other benchmarks

[Stephen Weeks]

> Ok,  first  things  first: the new coalescer seems pretty bad in terms of run
> time:
>                         old CPU        new CPU          change
>         knuth-bendix     34.77          36.23           -4.2%
>         lexgen           65.79          67.62           -2.8%
>         mlyacc           41.43          41.54           -0.3%
>         ratio-regions    46.54          37.80           23.1%
>         simple           44.07          39.06           12.8%
>         vliw             41.14          44.78           -8.8%

I'd still consider this a win on the whole.  Code size also should
have improved.

> Despite these lousy results, the trampoline counts all improved,  except  for
> VLIW, which is what I was trying to do:
> 
>         knuth-bendix     5,970,302       4,693,902
>         lexgen          18,588,580      13,094,922
>         mlyacc          21,570,876      18,862,276
>         ratio-regions   65,436,666       2,494,240
>         simple          78,110,715      57,506,745
>         vliw            45,479,093      52,652,798

I think there's still quite a bit of room for improvement.

> As to counts, for number of returns, there was no change,  except  for  vliw.
> The  old  coalescer  resulted  in  code  which  did  34,952,740 while the new
> coalescer produced code which did 34,952,695.  Not much of a change, but  I'm
> confused.
...
> Any explanations?

The only thing I can think of is a MLton bug, especially for the
return counts.

I guess we could instrument MLTON_limitCheck (in include/mlton-lib.h)
to output the line number and number of bytes in the check and see the 
first place where the number of bytes differs between the two
versions.

As for MLTON_return, I don't see any good way to instrument that.  The
"return address" (i.e. uint) in the stackTop is dependent on the
assignment of integers to labels, which is quite dependent on
coalescion.