[MLton] Flatten Benchmarks

[Stephen Weeks]

> It's not completely clear that ref of tuples into a (flattened)
> tuple of refs will be a win; certainly separating them out opens up
> the opportunity to do some optimization on each element.  On the
> other hand, if the individual elements end up having pointer's, then
> you pay for the write barrier at each ref update.

There's also the extra space used by having a ref object for each
element as opposed to a single ref for the whole tuple.

> Not too surprising if you look at the code; some really huge tuples of
> floats, and floats are expensive to move around.
> 
> > psdes-random        1.00   1.49     <-- best case
> 
> I find that a little surprising, as there doesn't seem to be much for any
> flattener to do in the code.

Yeah, this deserves investigating.  It may be noise.  Another thing to
look in addition to the SSA before and after the flatten pass is the
total bytes allocated (from @MLton gc-summary --), which presumably
would change if the flattener were doing much.