wasmtime / issue #4427 s390x: Implement full SIMD support · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #4427 s390x: Implement full SIMD support

Wasmtime GitHub notifications bot (Jul 09 2022 at 19:22):

Unfortunately there seems to be another QEMU problem. I'm now using a new s390x instruction to implement the "pseudo" min/max semantics, and this seems to be incorrectly implemented on QEMU. This causes the pmin/pmax tests (both the cranelift runtests and the wasm spec tests) to fail under QEMU, even though the all pass on native hardware (both z14 and z15).

I've now disabled those test to make the CI pass. Once we've fixed QEMU they can be re-enabled again.

Wasmtime GitHub notifications bot (Jul 11 2022 at 15:51):

alexcrichton commented on issue #4427:

If you're interested in @uweigand one thing that might be good to double-check this PR is to run some of the fuzzers for awhile locally on real hardware since QEMU-based performance on our end probably won't end up fuzzing much. For SIMD fuzzing the v8 fuzzer probably won't work since I suspect that the v8 Rust crate doesn't have prebuilt binaries for s390x (or actually I'm not sure v8 even has support for s390x...) but the differential_spec fuzzer might work? If OCaml works on s390x then that should be enough to get the differential_spec fuzzer running and if you run that for a few hours it might be good to weed out possible issues with simd-related (or other perhaps) instructions.

Wasmtime GitHub notifications bot (Jul 11 2022 at 16:38):

uweigand commented on issue #4427:

Hmm, unfortunately cargo fuzz run differential_spec fails immediately with:
error: address sanitizer is not supported for this target
which is a bit strange since LLVM on SystemZ does support the address sanitizer. But I guess there might be some bits of support in the Rust compiler itself that are missing? Do you have any pointers what we'd need to do here?

OCaml does work SystemZ, but I don't think it's even getting that far yet.

Wasmtime GitHub notifications bot (Jul 11 2022 at 16:40):

alexcrichton commented on issue #4427:

If you pass -s none to cargo fuzz does it make more progress? (that disables asan)

Wasmtime GitHub notifications bot (Jul 11 2022 at 16:41):

alexcrichton commented on issue #4427:

Ah sorry, and for fuzzing, the supported_sanitizers option in the upstream rust-lang/rust target specification I think is probably what's gating this on the s390x target. There may also be distribution bits as well, although I'm less certain about that.

Wasmtime GitHub notifications bot (Jul 11 2022 at 16:58):

uweigand commented on issue #4427:

With -s none the build completed successfully, and the fuzzer seems to be running now. Hasn't found anything yet - I'll just leave it running for a while. Thanks!

Wasmtime GitHub notifications bot (Jul 12 2022 at 15:23):

uweigand commented on issue #4427:

The fuzzer did indeed find two problems, both were detected after only a few minutes of running:

a problem with random high bits in sub-word immediates that were not properly zero-extended

a regalloc problem caused by inaccurate tracking of use of the %r1 temp register

I've now updated this PR to included fixes for both of those. With this fixed, the fuzzer has now been running for over 12 hours without finding anything, currently coming up to:
=== Execution rate (2717815 executed modules / 4171000 tried modules): 65.15979381443299% ===
(not sure if that is a lot or not ... or how long it makes sense to keep it running)

Wasmtime GitHub notifications bot (Jul 12 2022 at 15:28):

alexcrichton commented on issue #4427:

It's at least some progress! In https://github.com/bytecodealliance/wasmtime/issues/4315 two bugs were found in the x86_64 implementation with a program in the wild, so our fuzzing as-is right now is only but so comprehensive. There's various efforts to improve things, but 12 hours of no more bugs is better than 0 hours at least!

Wasmtime GitHub notifications bot (Jul 18 2022 at 20:43):

uweigand commented on issue #4427:

I did notice in some cases in lower.isle special cases -- actually the way in which shuffle uses pattern-matching is quite beautiful -- and was wondering if there were compile-tests that hit these special-cases in particular (vs relying on the Wasm testsuite and existing runtests).

Yes, cranelift/filetests/filetests/isa/s390x/vec-permute.clif has a compile test for each of the special cases.

Otherwise, I'm happy to see this merged!

Thanks for the review!

Last updated: Nov 22 2024 at 16:03 UTC