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.
867: Initial implementation of `assert_uninstantiable`. r=nlewycky a=nlewycky
# Description
Add a basic implementation of `assert_uninstantiable` in the spectest runner. Fixes one line of spectests in all three backends.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
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>
884: Show the full hex value of a float that fails assert returns arithmetic nan or assert returns canonical nan. r=nlewycky a=nlewycky
Co-authored-by: Nick Lewycky <nick@wasmer.io>
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.
880: Remove usage of LZCNT and TZCNT from singlepass. r=nlewycky a=nlewycky
# Description
This PR removes usage of LZCNT and TZCNT in singlepass to work on machines that don't support them. Unlike other instructions that fail loudly when not supported, LZCNT and TZCNT silently change behaviour by falling back to BSR and BSF which may produce different answers. They were used in the I32Clz, I32Ctz, I64Clz and I64Ctz instructions. Fixes i32.wast and i64.wast test failures on our Mac buildbot.
As an alternative, we could detect presence of LZCNT and TZCNT at runtime, either by running them directly or by querying CPUID to detect whether the CPU claims support for these instructions. I decided against that because having multiple paths is more complicated, and we aren't concerned with runtime of singlepass code, as a rule.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
Co-authored-by: nlewycky <nick@wasmer.io>
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…
