[MLton] an analysis to flatten refs into tuples

[Stephen Weeks]

> The ref flattening is really a nice optimization, but as a MLton user I'd 
> like some help from the compiler to warn me when refs that I expect to be 
> flattenable aren't.

I agree this could be helpful in some situations, and I agree with
Matthew that it's very hard and could create other problems.

Since the main point (I think) of introducing such an annotation would
understanding performance, I'll point at a few other ways of learning
similar information.  First, one could use MLton.size to measure the
size of your data structures, and as part of your regression suite,
make sure that this size doesn't change.  We do this with the ILs in
MLton.  Unfortunately, one drawback of MLton.size is that it does
interfere with the program.  A less direct, and completely safe, way
of measuring allocation is to run your executable with @MLton
gc-summary.  Again, you can use this while you are developing your
code to observe when there are significant changes in allocation
behavior.  If so, you know something has gone wrong, either in your
code or the optimizer.  I do this with MLton all the time.

Finally, you can use -profile alloc to measure where your code is
allocating.  It should give you completely accurate information on how
much allocation your cons function is doing.

>      fun cons (x,y) = (ref x,ref y)

Dividing that amount by the number of conses (obtained directly or by
-profile count) should tell you exactly what's going on.

Using high-level tools like the profiler seems a better way to me of
understanding performance behavior rather than focusing on
micro-optimizations in the compiler.  It's more robust, and lets you
focus directly where there are problems.

> With the ref flattening and the bit packing optimizations, I'm really 
> tempted to write a naive Scheme to ML source to source translator, and see 
> how well MLton does with the output... If MLton will "do the right thing" in 
> this case, I'd be very happy.

If the naive translator introduces a single universal type for all
scheme values, then MLton isn't likely to do much.  For almost all of
its analyses, MLton merges together information from all applications
of a given constructor.  So, it is unlikely to simplify the universal
datatype significantly.  About the best I can see is that the packing
stuff will avoid boxing small variants of the universal datatype (like
characters).