Re: Re: MLton codegen combines divison on arm

On Mon, Oct 25, 2010 at 5:09 PM, Wesley W. Terpstra <[email protected]> wrote:
> On Mon, Oct 25, 2010 at 10:52 PM, Wesley W. Terpstra <[email protected]> wrote:
>> There must be a toggle
>> somewhere in MLton that is letting it think that it is safe to
>> optimize away the division, but I can't for the life of me find it.
>
> I think I've found the problem! It will take two days before I know
> for sure, though.
>
> The problem isn't a flag, but that my mlton compiler was built before
> I wrote the fix. It decides that 1.0/10.0 is safe to optimize if when
> it does the calculation with TO_NEGINF and TO_POSINF the result comes
> out the same. Since fesetround was broken, the compiler always got the
> same result (even though it shouldn't). Thus, it decided it was safe
> to optimize 1.0/10.0 away. Presumably a complete two-stage rebuild of
> the compiler will incorporate the fix into the compiler and then when
> it compiles the regression, it will pass.

Were you able to declare success with the ARM floating-point rounding?

Your analysis of the source of the problem sounds right; perhaps the
floating-point constant folding should be further predicated.

The floating-point constant folding is predicated upon the host and
target platforms being equal.  So, a cross-compile of ieee-real.sml to
ARM from a non-ARM platform should leave the floating-point operations
unfolded.