The outputs of Wasmtime are inconsistent across different platforms

[ping ping]

I constructed a wasm binary with an exported function called "main". I compared the outputs of wasmtime and found they are inconsistent across different platforms.
file86.zip

Wasmtime v18.0.2 Ubuntu22.04 x86_64:

wasmtime --invoke main file86.wasm
warning: using `--invoke` with a function that returns values is experimental and may break in the future
667210185897120983469013534608098645
667210185897120983469013534608098645
667210185897120983469013534608098645
667210185897120983469013534608098645
667210185897120983469013534608098645
667210185897120983469013534608098645
667210185897120983469013534608098645

Wasmtime v18.0.2 MacOS arm64:

wasmtime --invoke main file86.wasm
warning: using `--invoke` with a function that returns values is experimental and may break in the future
667210185936411072606488982786049365
667210185936411072606488982786049365
667210185936411072606488982786049365
667210185936411072606488982786049365
667210185936411072606488982786049365
667210185936411072606488982786049365
667210185936411072606488982786049365

[bjorn3]

Does the wasm module look at the raw bits of floats? NaN values are allowed to be non-deterministic by the wasm specification. Different cpu architectures have different handling of NaN values. This may be the cause of the difference here if the answer to my question is true.

[Alex Crichton]

I can confirm locally that wasmtime run --invoke main -W nan-canonicalization file86.wasm produces the same result on both systems, whereas without it different results are produced. Given that I don't believe that there's a bug here since NaN is allowed to be nondeterministic across platforms and is a known part of the wasm spec.