[MLton] MLton calling convention and closure conversion

[Stephen Weeks]

Your explanation of MLton's trampoline is accurate.

> Therefore, isn't this whole goto/switch/trampoline infrastructure  
> unnecessary and possibly slow? Since MLton is tied to gcc for its  
> assembler anyways, why not use these extensions?

It may be unnecessary but I doubt it is slow, i.e. I doubt that it
significantly affects performance.  MLton does a good job of putting
basic blocks with control-flow edges between them in the same chunk so
that interchunk jumps are relatively rare.  As to replacing intrachunk
jumps with gcc tail calls, it's hard to imagine how that could be
faster.

> I was wondering, however, how deeply the flow analysis goes: can it
> always eliminate the need for a function pointer?

That depends on what you mean by "function pointer".  The output of
the closure conversion pass in MLton does not have any function
pointers in the sense of "address of code".  However, it does have
variant tags on environment records that allow it to distinguish
between different functions and branch to the right code.  The variant
tags are analogous to function pointers, and the case expressions that
do the branching implement the jump.

In the paper, figure 6, which I think is the example that made sense
to you, still has "case" expressions on such sum types in the target
program.  The tags "C5", "C6", "C7", and "C8" are variant tags
analogous to function pointers.

> (for example if I had an event heap with a callback function for
> each event, where many different events are registered all over the
> program)

Right.  Those will likely all get merged into the same sum type, and
the event dispatch will do a case.

> Finally, it seems to me that the functor and polymorphism elimination  
> via code replication and MLton's closure conversion are probably the  
> main reasons that MLton is so fast(?). 

Yes they are essential.  Although if you turn off some of the
subsequent optimization (e.g. flattening) you will see that it is
essential too.