[MLton] an analysis to flatten refs into tuples

[Matthew Fluet]

> I am planning on implementing an SSA pass to flatten ref cells into
> tuples.

Sounds good.  From the rest of your mail, you don't seem to consider the
more general case of flattening into datatypes.  Maybe that can fall out
as a special case of considering a datatype variant's arguments as a
1-tuple?

> Obviously, implementing this requires changing the SSA type system and
> IL to add the new mutable field in tuple types and new expressions to
> get and set mutable fields.  I think that's all pretty
> straightforward.

It will also ripple into the representation pass, but pretty quickly we
get to a point where mutable fields are in the IL, so that's not a
problem.

> The local analysis checks when a ref creation corresponds
> to a tuple creation (i.e., we see val x = ref y; val z = (x, w)) and
> when a ref that is extracted is only ever assigned to (i.e. we see val
> r = #2 z; val () = r := x).

Don't you also want to allow a dereference in the project case?
Otherwise, it seems like the ref is pretty useless.

I don't know if your examples above were meant to imply that the local
analysis was _really_ local and exclusively looking for these patterns, or
if you were considering a more general, but still local analysis.

This local analysis reminds me a lot of the local ref analysis.  And, I
think you need to be concerned with the same problems of escaping refs.
Remember, in the multi-threaded case, a ref can also escape to the stack
across a non-tail call.

> The global analysis uses abstract values similar to those we use for
> whole-program constant propagation or useless analysis.

Sounds right.

> The only problem I can see is one of space safety.  By keeping the
> containing tuple alive just so we can access the field, we are
> conceivably holding on to data that would otherwise be dead.  In
> practice I don't know if this would be bad.  If it is, perhaps the
> local analysis can be made strict enough to avoid such cases.

True, it doesn't seem like a likely case.  Seems like it would be pretty
easy to modify the local analysis to rule out the refs that would extend
the def-use extent of their corresponding tuples.