Inconsistent result on riscv64 with `fmul`, compared to other architectures

[akldc]

.clif Test Case

test optimize    
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true
            

function %main() -> f64x2 fast {
    const0 = 0x66dcb93ce18195cd25ba9b1858b0b8d5
    
block0:
    v14 = vconst.f64x2 const0
    v16 = bor_not v14, v14  ; v14 = const0, v14 = const0
    v80 = fmul.f64x2 v14, v16  ; v14 = const0
    return v80
}

; print: %main()

Result

Run this test case on four architectures.

[x86    ] %main() -> 0xffffffffffffffffffffffffffffffff
[aarch64] %main() -> 0xffffffffffffffffffffffffffffffff
[riscv64] %main() -> 0x7ff80000000000007ff8000000000000
[s390x  ] %main() -> 0xffffffffffffffffffffffffffffffff

The result on riscv64 differs from the other architectures.

[akldc]

@alexcrichton Any follow‑up on this issue? I’ve found a few other related cases.

[alexcrichton]

Alas we don't have any one actively working on the riscv64 backend at this time. I took a glance and I don't immediately know the solution myself, but I'm also pretty unfamilar with riscv64's vector extension. I do think that these issues are valuable nevertheless, but if you've got some related issues it might make sense to drop more tests on the current issues instead of opening new issues?

If you're curious to continue to do this testing it may make sense to exclude riscv64 for now until these preexisting issues have been fixed too.

[akldc]

@alexcrichton
Ok, we won't be opening new issues for similar problems for now. We're very interested in Cranelift, and we might report new issues in the future if we run into something more meaningful or with different behavior — like issues related to other architectures such as aarch64 or s390x.

[alexcrichton]

That seems reasonable yeah, I'm going to try again to poke at a few of these and see if I recognize them. FWIW if you're curious I'd be quite interested to hear more about what you're doing in in the Cranelift project meeting and I'm sure others would as well, so you're welcome to join if you'd like!

---

For this specific issue after digging in a bit I believe this is expected behavior. The results here are f64x2(NaN, NaN) and Cranelift doesn't guarantee deterministic NaN patterns across platforms. If I add set enable_nan_canonicalization=true I get the same result on riscv64 and x86 so this issue is otherwise working as intended. Now the others definitely look like legitimate issues though...

[cfallin]

FWIW if you're curious I'd be quite interested to hear more about what you're doing in in the Cranelift project meeting and I'm sure others would as well, so you're welcome to join if you'd like!

I'll second this -- thanks for doing this round of fuzzing; and we're always interested in finding new ways of adding to our testing.