Too aggressive optimizer?

[Stephen Weeks]

> So, I have a CPS program that unoptimized contains 375 references to an
> external C primitive in the outputed code. Once I turn the optimizer on that
> C primitve occurs 1377 times.  Is mlton assuming the primtives are pure and
> just engaging in very aggressive inlining, 

MLton assumes that Cprims have side effects (see maySideEffect in
atoms/prim.fun).  MLton also has (overly) aggressive inlining.  This
could certainly duplicate calls to a primitive.

> or is it doing some very fancy
> control analysis and assuming the primtives maybe impure?
> Or is this just a bug?

I'm not sure why you would think this is a bug or require fancy
analysis.  Consider the following example, where p is a Cprim.

fun f() = p()
val _ = f()
val _ = f()

A simple optimizer can easily and correctly produce

val _ = p()
val _ = p()

You can control the inlining somewhat with Control.inline.  Or better
yet, write your own :-)