Re: MLton codegen combines divison on arm

On Thu, Nov 11, 2010 at 3:15 PM, Matthew Fluet <[email protected]> wrote:
> Were you able to declare success with the ARM floating-point rounding?

No. After I fixed this problem I ran into the problem that libm didn't
respect the rounding mode for things as simple as 'round'!

What I was trying to do was throw some compile flags on the arm build
to use VPU instructions for our generated code. As I didn't recompile
libm, this didn't suffice to get regressions to pass.

On arm systems which have a VPU (floating put unit in "arm speak") and
have had their libc&gcc compiled to use it, a full build of MLton will
probably work and pass the regressions. The problem is that debian
libc/etc is built using soft-float.

Soft-float doesn't support arm rounding modes. After looking at the
libgcc source code that implements the software arithmetic, I found
that the library they use can do it, but it hard-wires the rounding
mode to TO_NEAREST. The problem is that libc controls the rounding
mode with fesetround and this has no way to communicate the new state
to libgcc. When I looked into fixing this problem, I was basically
told "you can't fix this without changing the arm EABI, and that can
only be done by professionals (TM)". Great.

It may also be the case that an accelerated assembler code is used in
some configurations. That assembler doesn't support rounding modes at
all. libgcc has several alternatives it can use for the floating point
implementation.

On debian, which targets the lowest-common-denominator hardware, libm
was built with this broken software emulation. Thus, the operations
inside it can't respect the rounding mode even though fesetround is
also a part of libc. It doesn't matter if you have a VPU or not, libm
continues to use broken software emulation and ruins the support.

Conclusion:
no VPU -> shit-out-of-luck because libgcc hardwires the software rounding mode
Debian -> shit-out-of-luck because libm was compiled using the libgcc emulation
VPU + distribution built to use it -> will already work out of the box
(since gcc will by default be using the VPU code generation and your
libm will have been built this way)

What needs to be done IMO is to turn on the rounding mode support in
libgcc. It's absurd that something as simple as wiring it to a public
symbol is considered a roadblock to fixing this problem. I don't have
the time or energy needed to try and push a change like this through
the sorts of people who gather around libc development.

> 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.

Yep.