[MLton-user] Tracking down allocations

[Matthew Fluet]

On Sun, 15 Jul 2007, Joe Hurd wrote:
> Thanks very much for your clarifications. I had a look at the .ssa
> file, and believe I have found the offending line:
>
>    Enter M.f src/t.sml: 342
>    Enter M.f.g.<branch> src/t.sml: 343
>    tuple_32 = (x_3050, x_3047, x_3049)  <-- Evil allocation

That would normally turn into an allocation.  (Looking at the .ssa2 file 
should turn up the same allocation.)

> The evil allocation line doesn't appear in the version where I
> manually un-nested the inner function. [This is not the big function f
> that I described in my initial mail, but a smaller function with the
> same structure. However, this nested function g is not "big but
> non-recursive", but rather small and mutually recursive.]
>
> I'm using a version of MLton compiled for darwin/i386:
>
> MLton MLTONVERSION (built Mon Oct 30 23:08:10 2006 on frogbat.local)
>
> Do you think it looks like a compiler bug (or at least oddity)?

I don't think it is a compiler bug -- as long as there is an allocation of 
some sort in the source program, then the compiler isn't changing the 
meaning of the program.  It is an oddity, especially if tuple_32 is 
immediately deconstructed.  If tuple_32 is passed as an argument to 
another SSA function, then it may be a case of the input programs being 
just different enough that the flattening optimization behaves differently 
on them.  As I noted before, the flattening optimization uses a heuristic, 
and doesn't flatten completely.