More floating point tests!

[sunfishcode]

This adds a bunch more tests focused on floating point.

Note that there are some minor inconsistencies in general with how NaNs are handled; I plan to address those separately as part of the work related to WebAssembly/design#660.

[sunfishcode]

Ping :-).

[kripken]

I skimmed the tests and things look good to me, although, most goes above my head ;)

However, the binaryen interpreter fails in float_exprs.wast on

(assert_return (invoke "f32.no_fold_div_0" (f32.const nan:0x200000)) (f32.const nan:0x600000))

I'm not sure I understand what is being tested there?

[jfbastien]

I skimmed the tests and things look good to me, although, most goes above my head ;)

However, the binaryen interpreter fails in float_exprs.wast on

(assert_return (invoke "f32.no_fold_div_0" (f32.const nan:0x200000)) (f32.const nan:0x600000))

I'm not sure I understand what is being tested there?

Looks like the bug is this last line:

  Literal div(const Literal& other) const {
    switch (type) {
      case WasmType::f32: {
        float lhs = getf32(), rhs = other.getf32();
        float sign = std::signbit(lhs) == std::signbit(rhs) ? 0.f : -0.f;
        switch (std::fpclassify(rhs)) {
          case FP_ZERO:
          switch (std::fpclassify(lhs)) {
            case FP_NAN: return *this;

AstSemantics says:

When the result of any arithmetic operation other than neg, abs, or copysign is a NaN, the sign bit and the fraction field (which does not include the implicit leading digit of the significand) of the NaN are computed as follows:
*If the operation has any NaN input values, implementations may select any of them to be the result value, but with the most significant bit of the fraction field overwritten to be 1.

• If the implementation does not choose to use an input NaN as a result value, or if there are no input NaNs, the result value has a nondeterministic sign bit, a fraction field with 1 in the most significant bit and 0 in the remaining bits.

So the requirement is to set 1 as the MSB of the fraction field, rest can be zero or the original value, and sign bit can be anything. The test seems over-constrained, but I also have a bug in binaryen. I'll fix :-)

[sunfishcode]

It's testing that a floating-point divide of a signaling NaN operand divided by an immediate zero returns a quiet NaN, per IEEE 754, and that the rest of the NaN payload and sign bit are propagated per wasm's rules, except that it's not yet updated for WebAssembly/design#660. I plan to update it when I update all the tests.

[binji]

optimized

[sunfishcode]

Fixed; thanks!

[jfbastien]

NaN / 0 fixed in WebAssembly/binaryen#442. It still seems like the test is over-constrained? For now all the implementations do "the right thing" so maybe just comment that it's over-constrained?

[sunfishcode]

Can you clarify in what way it's over-constrained?

[jfbastien]

Can you clarify in what way it's over-constrained?

I'm not sure if I'm misunderstanding, but this seems to give leeway to implementations:

• If the operation has any NaN input values, implementations may select any of them to be the result value, but with the most significant bit of the fraction field overwritten to be 1.
• If the implementation does not choose to use an input NaN as a result value, or if there are no input NaNs, the result value has a nondeterministic sign bit, a fraction field with 1 in the most significant bit and 0 in the remaining bits.

It sounds like the sign can be whatever, and the NaN can propagate to quiet (same payload, but not signaling) or be quiet NaN with zeroes as fraction. Is that correct?

[sunfishcode]

That's the new text in WebAssembly/design#660. Many existing tests also need to be updated as well. I plan to do all the updates at once.

[jfbastien]

That's the new text in WebAssembly/design#660. Many existing tests also need to be updated as well. I plan to do all the updates at once.

Ah right, ty! /me unconfused

[jfbastien]

High-level lgtm!

[sunfishcode]

Merging, with high-level lgtm, since these just add new tests with no spec changes. As always, these and all tests continue to be open to comments and questions.

[rossberg]

Sorry, I was away. Also LGTM