[MLton-user] MLton misbehaving?

[Matthew Fluet]

On Wed, 30 Apr 2008, Johan Grönqvist wrote:
> This version of teh program raises an unhandled exception. In order to 
> debug, I compile with -const 'Exn.keepHistory true', but then no 
> unhandled exception is raised, and the program keeps runing happily.

Keeping the exception history shouldn't change the behavior of the 
program, except for the MLton.Exn.history function and (therefore) the 
top-level uncaught exception handler.

However, keeping the exception history does change the program as seen by 
the compiler, so different compiler optimizations may occur (or fail to 
occur).  As Vesa noted, x86 floating-point computation rounding is 
affected by the generated code (in particular, when floating-point values 
are written to memory due to register spilling or calling conventions). 
Thus, it is not surprising that you get different floating-point results 
when compiled in the two modes (or even if you make seemingly inoccous 
changes to the source program).

Though, it is not impossible that the exception history leads to an 
incorrect program transformation by the compiler.  Seeing the program 
might help.

> I use mlton verion MLton 20070826 (built Wed Aug 29 09:44:07 2007 on 
> silver-star.cs.uchicago.edu) that I installed from precompiled archive 
> downloaded from mlton.org on a computer running suse (10.0, I believe)

So, this occurs on an x86-linux platform.

> The program essentially minimizes a polynomial in many variables, and 
> then writes data to files before exiting. Most of the code is for 
> bookkeeping on the variables, and for extracting data. The unhandled 
> exception Bug that is raised by the rogram should only be raised when I 
> have made a mistake in the code or an incorrect assumption about the 
> code. I never hadle such exceptions. I do not use any additional 
> libraries, and do not use any C-like facilities. I do not use infinite 
> precision integers.

Is the Bug exception raised in response to floating-point calculations?

> Commenting out the last five of those lines prevents the unhandled
> exception from being raised.
>
> I comment out the 5 lines, and run the same script again
> The output is then (warnings deleted again)

Changing the input program in this manner, for example, might result in 
csnw_minimized being inlined, if there is now only one call to the 
function in the program.  That, in turn, might change how floating-point 
values are spilled, flattened, etc.

As Vesa noted, the '-ieee-fp true' compiler option will instruct the 
compiler to write every floating-point value to memory immediately after 
it is computed.  That maximizes the rounding (and approximates true 64-bit 
IEEE calculations) by always discarding the extra precision of the x86 
80-bit floating-point registers.

Alternatively, if you have access to an amd64 machine, the MLton 
native-codegen will use the SSE instructions to perform all (primitive) 
floating-point calculations at exactly 64-bit IEEE.  That tends to be 
much more robust to program transformations.