Stream: git-wasmtime

Topic: wasmtime / PR #12963 Cranelift: apply NaN canonicalizatio...

view this post on Zulip Wasmtime GitHub notifications bot (Apr 04 2026 at 18:27):

tschneidereit opened PR #12963 from tschneidereit:nan-canon-libcalls to bytecodealliance:main:

This probably doesn't matter much in the real world, since the libcalls are only emitted on pre-SSE4.1 x64, and hence on CPUs released before 2007 (Intel) and 2011 (AMD). It does trip up the cranelift-fuzzgen fuzzer though, since the libcalls are interpreted differently between Pulley and Cranelift. In a local (Aarch64, which I think matters) run of maybe an hour, I got 30 artifacts based on this, inhibiting other explorations.

Alternatively, we could make SSE4.1 a requirement and remove the libcalls entirely: they're unused on all other platforms.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 04 2026 at 18:27):

tschneidereit requested fitzgen for a review on PR #12963.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 04 2026 at 18:27):

tschneidereit requested wasmtime-compiler-reviewers for a review on PR #12963.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 04 2026 at 18:34):

tschneidereit updated PR #12963.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 04 2026 at 21:50):

github-actions[bot] added the label cranelift on PR #12963.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2026 at 14:26):

alexcrichton submitted PR review:

Thanks! Would it be possible to add some tests for this as well?

Additionally, I think it's ok to exempt CallIndirect and instead match on the call target of Call to ensure that this is only applied to libcalls as opposed to all functions in general.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2026 at 14:37):

cfallin commented on PR #12963:

Alternatively, we could make SSE4.1 a requirement and remove the libcalls entirely: they're unused on all other platforms.

This has definitely crossed my mind at several points in the past too (it's very annoying to have to polyfill things) but FWIW, we made a somewhat explicit decision a few years ago to try to support everything on x86-64 all the way back to the first x86-64 (so, just SSE2) -- and actually Alex did most of the SIMD work for that -- so we would have the strongest possible "we support x86" story :-) At some point it may become so unimportant that we can drop it but for now at least it feels nice to keep if we can (so, thanks for the work to include libcalls here!).

Last updated: Apr 12 2026 at 23:10 UTC