Stream: cranelift

Topic: floating point nondeterminism?

view this post on Zulip fitzgen (he/him) (Mar 16 2020 at 18:38):

How much nondeterminism do we expect from wasm / in cranelift with regards to floating point numbers? I know there is some, but I'm not actually familiar with where it comes from. https://webassembly.org/docs/nondeterminism/ suggests that this should just be the sign bit of NaNs.

Asking because the fuzzers have found a Wasm test case that returns different floating point values when compiled with and without optimizations, and I'd like to know whether to investigate further or to disable differential fuzzing on wasm that contains floating point numbers. Or just ignore NaNs? FWIW, for this test case, neither returned value is a NaN.

+cc @Dan Gohman

view this post on Zulip Dan Gohman (Mar 16 2020 at 19:56):

We expect floating-point numeric results to be fully deterministic.

view this post on Zulip Dan Gohman (Mar 16 2020 at 19:57):

I'd be very interested in a case where disabling optimization changes a numeric (non-NaN) result.

view this post on Zulip Dan Gohman (Mar 16 2020 at 19:58):

FWIW, Cranelift also has a canonicalize_nans flag which causes it to generate fully deterministic NaNs too, which may be useful for fuzzing.

view this post on Zulip fitzgen (he/him) (Mar 16 2020 at 22:25):

Filed https://github.com/bytecodealliance/wasmtime/issues/1331 for the differential fuzzing issue. Still working on reducing the test case further.

Cranelift: different results when Wasm module is compiled without optimizations vs with speed-and-size optimizations · Issue #1331 · bytecodealliance/wasmtime
This test case, produced by wasm-opt -ttf, produces different results for function 5 when compiled with speed-and-size optimizations vs without any optimizations: WAT test case (module (type (;0;) ...

view this post on Zulip fitzgen (he/him) (Mar 16 2020 at 22:35):

And filed https://github.com/bytecodealliance/wasmtime/issues/1332 for canonicalizing NaNs when fuzzing

Canonicalize NaNs when fuzzing · Issue #1332 · bytecodealliance/wasmtime
In Config::new in crates/api/src/runtime.rs, we should conditionally enable the canonicalize_nans cranelift option when we're being built for fuzzing: #[cfg(fuzzing)] flags.set("enable_nan...

view this post on Zulip Dan Gohman (Mar 16 2020 at 22:35):

When I run the .wat file manually with wasmtime --invoke func_5, in a build with debug-assertions enabled, I get a cranelift IR verifier error, in what looks like a regalloc problem

view this post on Zulip fitzgen (he/him) (Mar 16 2020 at 23:24):

tracked down why the fuzz targets weren't failing in the verifier: https://github.com/bytecodealliance/wasmtime/pull/1333

care to review that @Dan Gohman ?

fuzzing: Enable Cranelift's IR verifier for differential fuzzing by fitzgen · Pull Request #1333 · bytecodealliance/wasmtime
The reason we weren't seeing the verifier errors in the fuzz targers in #1331 but were seeing them via wasmtime --invoke was because the differential fuzzing configs forgot to enable the IR ver...

view this post on Zulip Dan Gohman (Mar 16 2020 at 23:25):

r+

view this post on Zulip Kirp (Apr 25 2024 at 13:23):

Dan Gohman said:

I'd be very interested in a case where disabling optimization changes a numeric (non-NaN) result.

I assume this means wasm spec disallows opts like gcc does with fast-math (eg a*b+c to fma(a, b, c)) and so they’re not (and will not) be implemented

Last updated: Dec 23 2024 at 12:05 UTC