877: Reimplement F32Min, F32Max, F64Min and F64Max. r=nlewycky a=nlewycky
# Description
Reimplement F32Min, F32Max, F64Min and F64Max.
Adds XMM8--15 registers. Adds VMOVA, VBLEND and VXORP, and the VCMPUNORD and VCMPORD comparisons.
Fixes 419 test failures.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
887: Get aggressive about running cargo check over all packages with all features. r=nlewycky a=nlewycky
Fixes the one issue uncovered. The capstone disassembling support in the LLVM backend was broken. Fixed by removing it. Instead, use the `--llvm-object-file` flag to get a finished object file to disassemble with any disassembler.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
Co-authored-by: Mark McCaskey <mark@wasmer.io>
889: fix(singlepass-backend) Use wasmparser from `runtime-core` r=Hywan a=Hywan
The `wasmer-runtime-core` crate re-exports the `wasmparser`
crate. This patch updates the `singlepass-backend` crate to use
`wasmparser` through the `wasmer-runtime-core` crate, which removes a
direct dependency for this crate.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
The `wasmer-runtime-core` crate re-exports the `wasmparser`
crate. This patch updates the `singlepass-backend` crate to use
`wasmparser` through the `wasmer-runtime-core` crate, which removes a
direct dependency for this crate.
Fixes the one issue uncovered. The capstone disassembling support in the LLVM backend was broken. Fixed by removing it. Instead, use the `--llvm-object-file` flag to get a finished object file to disassemble with any disassembler.
885: fix(cranelift-backend) Remove broken (and useless?) debug code r=nlewycky a=Hywan
This debug code is broken (it doesn't compile). It can be assumed
nobody uses it, and can be considered as dead code. As such, this PR
removes it.
The `debug` feature is kept in `Cargo.toml` to activate `wasmer-runtime-core/debug`.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
Instead of ensuring outputs are arithmetic NaNs on every function, we tag them as pending such a check, so that a sequence of computation can have a single canonicalization step at the end.
There's an extra wriggle for SIMD. The Wasm type system only indicates them as V128, so it's possible that we might do computations as F32x4Add, I8x16Add, F64x2Add in a row with no other computations in between. Thus, most SIMD functions apply pending canonicalizations to their inputs, even integer SIMD operations.
After a long time, the macros are easy to read, but not at first
glance. I hope this PR will improve the situation: Same syntax used
everywhere, more spaces…
