uweigand commented on issue #4427:
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.
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 thedifferential_spec
fuzzer might work? If OCaml works on s390x then that should be enough to get thedifferential_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.
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.
alexcrichton commented on issue #4427:
If you pass
-s none
tocargo fuzz
does it make more progress? (that disables asan)
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.
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!
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 registerI'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)
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!
uweigand commented on issue #4427:
I did notice in some cases in
lower.isle
special cases -- actually the way in whichshuffle
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: Dec 23 2024 at 13:07 UTC