[MLton] Constant Folding of FP Operations

[Vesa Karvonen]

Attached is an experimental patch that improves MLton's constant folding
of floating point operations.  The problem with constant folding FP
operations in SML is that the FP ops are subject to rounding mode
settings:

  http://www.standardml.org/Basis/ieee-float.html#SIG:IEEE_REAL.setRoundingMode:VAL

The workaround used in the patch is to evaluate the operations in all
rounding modes (actually in only TO_NEGINF and TO_POSINF) and check that
the results agree.  This ensures that constant folding is correct in all
rounding modes.

Personally I'm inclined to think that the inclusion of get/setRoundingMode
in the Basis library is a design mistake, because it makes some FP
optimizations very difficult.  An alternative design would be to have
multiple modules, say Real[ToNearest], RealToNegInf, RealToPosInf, and
RealToZero, each corresponding to a specific rounding mode.  FP ops could
then be treated as functional and it would then likely become
straightforward to make the same kind of aggressive constant folding and
simplification of FP ops as is done for integer ops.  Of course, this
would introduce the need for the compiler to insert code to switch the
rounding modes when necessary, but this doesn't seem extremely difficult.

About the patch.  The compiler changes do not compile with SML/NJ, which
does not support 32-bit floating point (Real32), and it should be made so
that the FP simplifications aren't performed (and would be replaced with
dummy functions) when the compiler has been compiled with SML/NJ.  This is
the reason why I consider this an experimental patch and haven't committed
it.  Some of the floating point simplifications should probably also be
disabled when cross compiling.  These should not be very difficult to do,
but it seems that I'm unlikely get around to implementing them.

The "decon" datatype has some constructors that aren't currently used
(although they are produced by the decon function) in the patch.  I
planned those constructors for some optimizations (e.g. replace divide by
a power of 2 with a multiply) that aren't currently possible with MLton's
Prim.apply, because it does not allow the introduction of an operation
with constants in the result of Prim.apply.  This restriction of
Prim.apply could probably be lifted without huge problems.  The limitation
is probably due to the design of the SSA and SSA2 intermediate languages
of MLton that do not allow constants as operands.

The purpose of the changes to real.sml in the basis library implementation
is to expose opportunities for constant folding.  Calls to the "class"
function cannot be optimized away (by the current compiler).

-Vesa Karvonen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: real-cf.patch
Type: text/x-diff
Size: 25462 bytes
Desc: not available
Url : http://mlton.org/pipermail/mlton/attachments/20080523/9b48dd47/real-cf-0001.bin