[MLton] ref flattening and backpatching

[Matthew Fluet]

> > I suspect it's fairly trivial to extend the refFlatten analysis to
> > also determine when the ref can be flattened as an immutable field
>
> Yes, this makes sense, and the immutability information could help
> other optimizations.
>
> > Although, I'm not sure whether this buys much -- as far as I know,
> > the only additional cost we pay for a flattened ref is the card mark
> > when it is mutated, which would be zero in the case I'm describing.
>
> I don't understand.  Whether a card mark occurs on a := only depends
> on whether the value being assigned is represented as a pointer or
> not.  Flattening the ref cell has no impact on that.  The impact of
> flattening is the space savings from not allocating the ref cell as a
> separate object.

I was making a comment concerning the flatten as an immutable field
optimization.  If refFlatten is the last optimization pass (i.e., no SSA
optimizations get to see the immutable field), then I don't think that the
Machine IL or codegen's will do anything functionally different in the two
cases.