[MLton] A couple of minor optimizations

[Matthew Fluet]

On Thu, 13 Dec 2007, Vesa Karvonen wrote:
> I was thinking about implementing rational numbers.  For an efficient
> library implementation it would seem important to me that the compiler can
> do constant folding on gcd (otherwise no constant folding can be performed
> on rational arithmetic at all).  So, I took a look at how MLton implements
> gcd and found out, pleasantly, that MLton's gcd is subject to constant
> folding.

Sort of.  The IntInf_gcd primitive will be constant folded.  But the 
MLton.IntInf.gcd function that is exported by the Basis Library has both a 
smallGcd path (for when both arguments are 'small') and the IntInf_gcd 
primitive path.  The smallGcd function is a recursive function, but is 
tail recursive, so should turn into a local loop.  However, even if it is 
inlined into a context where it is called with constants, I'm not sure 
that it will actually succeed in constant folding; MLton doesn't do any 
loop unrolling, so I think the constants will just sit at the loop entry.

> IntInf_gcd does not seem to be recognized as a commutative operation by
> MLton, which seems to have an effect on common subexpression elimination.
> I assume this is merely an oversight.
>
> Similarly, I noticed that Real_qequal is considered commutative,
> but Real_equal isn't.  As far as I can see, Real_equal is also
> commutative.
>
> I also noticed that Real_abs and Real_neg have been marked as
> DependsOnState.  This seems unnecessarily pessimistic, because both of
> those operations only manipulate the sign bit (clear and invert it,
> respectively) and don't depend on the rounding mode.
>
> So, below is small patch that (re)enables the corresponding optimizations.

All of those seem great.  Feel free to apply and commit it.