|
|
|
//! Build program to generate a program which runs all the testsuites.
|
|
|
|
//!
|
|
|
|
//! By generating a separate `#[test]` test for each file, we allow cargo test
|
|
|
|
//! to automatically run the files in parallel.
|
|
|
|
|
|
|
|
use anyhow::Context;
|
|
|
|
use std::env;
|
|
|
|
use std::fmt::Write;
|
|
|
|
use std::fs;
|
|
|
|
use std::path::{Path, PathBuf};
|
|
|
|
use std::process::Command;
|
|
|
|
|
|
|
|
fn main() -> anyhow::Result<()> {
|
|
|
|
println!("cargo:rerun-if-changed=build.rs");
|
|
|
|
|
|
|
|
let out_dir = PathBuf::from(
|
|
|
|
env::var_os("OUT_DIR").expect("The OUT_DIR environment variable must be set"),
|
|
|
|
);
|
|
|
|
let mut out = String::new();
|
|
|
|
|
|
|
|
for strategy in &["Cranelift"] {
|
|
|
|
writeln!(out, "#[cfg(test)]")?;
|
|
|
|
writeln!(out, "#[allow(non_snake_case)]")?;
|
|
|
|
writeln!(out, "mod {} {{", strategy)?;
|
|
|
|
|
|
|
|
with_test_module(&mut out, "misc", |out| {
|
|
|
|
test_directory(out, "tests/misc_testsuite", strategy)?;
|
|
|
|
test_directory_module(out, "tests/misc_testsuite/multi-memory", strategy)?;
|
|
|
|
test_directory_module(out, "tests/misc_testsuite/simd", strategy)?;
|
|
|
|
test_directory_module(out, "tests/misc_testsuite/threads", strategy)?;
|
Implement the memory64 proposal in Wasmtime (#3153)
* Implement the memory64 proposal in Wasmtime
This commit implements the WebAssembly [memory64 proposal][proposal] in
both Wasmtime and Cranelift. In terms of work done Cranelift ended up
needing very little work here since most of it was already prepared for
64-bit memories at one point or another. Most of the work in Wasmtime is
largely refactoring, changing a bunch of `u32` values to something else.
A number of internal and public interfaces are changing as a result of
this commit, for example:
* Acessors on `wasmtime::Memory` that work with pages now all return
`u64` unconditionally rather than `u32`. This makes it possible to
accommodate 64-bit memories with this API, but we may also want to
consider `usize` here at some point since the host can't grow past
`usize`-limited pages anyway.
* The `wasmtime::Limits` structure is removed in favor of
minimum/maximum methods on table/memory types.
* Many libcall intrinsics called by jit code now unconditionally take
`u64` arguments instead of `u32`. Return values are `usize`, however,
since the return value, if successful, is always bounded by host
memory while arguments can come from any guest.
* The `heap_addr` clif instruction now takes a 64-bit offset argument
instead of a 32-bit one. It turns out that the legalization of
`heap_addr` already worked with 64-bit offsets, so this change was
fairly trivial to make.
* The runtime implementation of mmap-based linear memories has changed
to largely work in `usize` quantities in its API and in bytes instead
of pages. This simplifies various aspects and reflects that
mmap-memories are always bound by `usize` since that's what the host
is using to address things, and additionally most calculations care
about bytes rather than pages except for the very edge where we're
going to/from wasm.
Overall I've tried to minimize the amount of `as` casts as possible,
using checked `try_from` and checked arithemtic with either error
handling or explicit `unwrap()` calls to tell us about bugs in the
future. Most locations have relatively obvious things to do with various
implications on various hosts, and I think they should all be roughly of
the right shape but time will tell. I mostly relied on the compiler
complaining that various types weren't aligned to figure out
type-casting, and I manually audited some of the more obvious locations.
I suspect we have a number of hidden locations that will panic on 32-bit
hosts if 64-bit modules try to run there, but otherwise I think we
should be generally ok (famous last words). In any case I wouldn't want
to enable this by default naturally until we've fuzzed it for some time.
In terms of the actual underlying implementation, no one should expect
memory64 to be all that fast. Right now it's implemented with
"dynamic" heaps which have a few consequences:
* All memory accesses are bounds-checked. I'm not sure how aggressively
Cranelift tries to optimize out bounds checks, but I suspect not a ton
since we haven't stressed this much historically.
* Heaps are always precisely sized. This means that every call to
`memory.grow` will incur a `memcpy` of memory from the old heap to the
new. We probably want to at least look into `mremap` on Linux and
otherwise try to implement schemes where dynamic heaps have some
reserved pages to grow into to help amortize the cost of
`memory.grow`.
The memory64 spec test suite is scheduled to now run on CI, but as with
all the other spec test suites it's really not all that comprehensive.
I've tried adding more tests for basic things as I've had to implement
guards for them, but I wouldn't really consider the testing adequate
from just this PR itself. I did try to take care in one test to actually
allocate a 4gb+ heap and then avoid running that in the pooling
allocator or in emulation because otherwise that may fail or take
excessively long.
[proposal]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md
* Fix some tests
* More test fixes
* Fix wasmtime tests
* Fix doctests
* Revert to 32-bit immediate offsets in `heap_addr`
This commit updates the generation of addresses in wasm code to always
use 32-bit offsets for `heap_addr`, and if the calculated offset is
bigger than 32-bits we emit a manual add with an overflow check.
* Disable memory64 for spectest fuzzing
* Fix wrong offset being added to heap addr
* More comments!
* Clarify bytes/pages
3 years ago
|
|
|
test_directory_module(out, "tests/misc_testsuite/memory64", strategy)?;
|
|
|
|
test_directory_module(out, "tests/misc_testsuite/component-model", strategy)?;
|
|
|
|
Ok(())
|
|
|
|
})?;
|
|
|
|
|
|
|
|
with_test_module(&mut out, "spec", |out| {
|
|
|
|
let spec_tests = test_directory(out, "tests/spec_testsuite", strategy)?;
|
|
|
|
// Skip running spec_testsuite tests if the submodule isn't checked
|
|
|
|
// out.
|
|
|
|
if spec_tests > 0 {
|
Implement the memory64 proposal in Wasmtime (#3153)
* Implement the memory64 proposal in Wasmtime
This commit implements the WebAssembly [memory64 proposal][proposal] in
both Wasmtime and Cranelift. In terms of work done Cranelift ended up
needing very little work here since most of it was already prepared for
64-bit memories at one point or another. Most of the work in Wasmtime is
largely refactoring, changing a bunch of `u32` values to something else.
A number of internal and public interfaces are changing as a result of
this commit, for example:
* Acessors on `wasmtime::Memory` that work with pages now all return
`u64` unconditionally rather than `u32`. This makes it possible to
accommodate 64-bit memories with this API, but we may also want to
consider `usize` here at some point since the host can't grow past
`usize`-limited pages anyway.
* The `wasmtime::Limits` structure is removed in favor of
minimum/maximum methods on table/memory types.
* Many libcall intrinsics called by jit code now unconditionally take
`u64` arguments instead of `u32`. Return values are `usize`, however,
since the return value, if successful, is always bounded by host
memory while arguments can come from any guest.
* The `heap_addr` clif instruction now takes a 64-bit offset argument
instead of a 32-bit one. It turns out that the legalization of
`heap_addr` already worked with 64-bit offsets, so this change was
fairly trivial to make.
* The runtime implementation of mmap-based linear memories has changed
to largely work in `usize` quantities in its API and in bytes instead
of pages. This simplifies various aspects and reflects that
mmap-memories are always bound by `usize` since that's what the host
is using to address things, and additionally most calculations care
about bytes rather than pages except for the very edge where we're
going to/from wasm.
Overall I've tried to minimize the amount of `as` casts as possible,
using checked `try_from` and checked arithemtic with either error
handling or explicit `unwrap()` calls to tell us about bugs in the
future. Most locations have relatively obvious things to do with various
implications on various hosts, and I think they should all be roughly of
the right shape but time will tell. I mostly relied on the compiler
complaining that various types weren't aligned to figure out
type-casting, and I manually audited some of the more obvious locations.
I suspect we have a number of hidden locations that will panic on 32-bit
hosts if 64-bit modules try to run there, but otherwise I think we
should be generally ok (famous last words). In any case I wouldn't want
to enable this by default naturally until we've fuzzed it for some time.
In terms of the actual underlying implementation, no one should expect
memory64 to be all that fast. Right now it's implemented with
"dynamic" heaps which have a few consequences:
* All memory accesses are bounds-checked. I'm not sure how aggressively
Cranelift tries to optimize out bounds checks, but I suspect not a ton
since we haven't stressed this much historically.
* Heaps are always precisely sized. This means that every call to
`memory.grow` will incur a `memcpy` of memory from the old heap to the
new. We probably want to at least look into `mremap` on Linux and
otherwise try to implement schemes where dynamic heaps have some
reserved pages to grow into to help amortize the cost of
`memory.grow`.
The memory64 spec test suite is scheduled to now run on CI, but as with
all the other spec test suites it's really not all that comprehensive.
I've tried adding more tests for basic things as I've had to implement
guards for them, but I wouldn't really consider the testing adequate
from just this PR itself. I did try to take care in one test to actually
allocate a 4gb+ heap and then avoid running that in the pooling
allocator or in emulation because otherwise that may fail or take
excessively long.
[proposal]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md
* Fix some tests
* More test fixes
* Fix wasmtime tests
* Fix doctests
* Revert to 32-bit immediate offsets in `heap_addr`
This commit updates the generation of addresses in wasm code to always
use 32-bit offsets for `heap_addr`, and if the calculated offset is
bigger than 32-bits we emit a manual add with an overflow check.
* Disable memory64 for spectest fuzzing
* Fix wrong offset being added to heap addr
* More comments!
* Clarify bytes/pages
3 years ago
|
|
|
test_directory_module(out, "tests/spec_testsuite/proposals/memory64", strategy)?;
|
|
|
|
test_directory_module(
|
|
|
|
out,
|
|
|
|
"tests/spec_testsuite/proposals/multi-memory",
|
|
|
|
strategy,
|
|
|
|
)?;
|
|
|
|
test_directory_module(out, "tests/spec_testsuite/proposals/threads", strategy)?;
|
|
|
|
test_directory_module(
|
|
|
|
out,
|
|
|
|
"tests/spec_testsuite/proposals/relaxed-simd",
|
|
|
|
strategy,
|
|
|
|
)?;
|
|
|
|
} else {
|
|
|
|
println!(
|
|
|
|
"cargo:warning=The spec testsuite is disabled. To enable, run `git submodule \
|
|
|
|
update --remote`."
|
|
|
|
);
|
|
|
|
}
|
|
|
|
Ok(())
|
|
|
|
})?;
|
|
|
|
|
|
|
|
writeln!(out, "}}")?;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Write out our auto-generated tests and opportunistically format them with
|
|
|
|
// `rustfmt` if it's installed.
|
|
|
|
let output = out_dir.join("wast_testsuite_tests.rs");
|
|
|
|
fs::write(&output, out)?;
|
|
|
|
drop(Command::new("rustfmt").arg(&output).status());
|
|
|
|
Ok(())
|
|
|
|
}
|
Implement the relaxed SIMD proposal (#5892)
* Initial support for the Relaxed SIMD proposal
This commit adds initial scaffolding and support for the Relaxed SIMD
proposal for WebAssembly. Codegen support is supported on the x64 and
AArch64 backends on this time.
The purpose of this commit is to get all the boilerplate out of the way
in terms of plumbing through a new feature, adding tests, etc. The tests
are copied from the upstream repository at this time while the
WebAssembly/testsuite repository hasn't been updated.
A summary of changes made in this commit are:
* Lowerings for all relaxed simd opcodes have been added, currently all
exhibiting deterministic behavior. This means that few lowerings are
optimal on the x86 backend, but on the AArch64 backend, for example,
all lowerings should be optimal.
* Support is added to codegen to, eventually, conditionally generate
different code based on input codegen flags. This is intended to
enable codegen to more efficient instructions on x86 by default, for
example, while still allowing embedders to force
architecture-independent semantics and behavior. One good example of
this is the `f32x4.relaxed_fmadd` instruction which when deterministic
forces the `fma` instruction, but otherwise if the backend doesn't
have support for `fma` then intermediate operations are performed
instead.
* Lowerings of `iadd_pairwise` for `i16x8` and `i32x4` were added to the
x86 backend as they're now exercised by the deterministic lowerings of
relaxed simd instructions.
* Sample codegen tests for added for x86 and aarch64 for some relaxed
simd instructions.
* Wasmtime embedder support for the relaxed-simd proposal and forcing
determinism have been added to `Config` and the CLI.
* Support has been added to the `*.wast` runtime execution for the
`(either ...)` matcher used in the relaxed-simd proposal.
* Tests for relaxed-simd are run both with a default `Engine` as well as
a "force deterministic" `Engine` to test both configurations.
* All tests from the upstream repository were copied into Wasmtime.
These tests should be deleted when WebAssembly/testsuite is updated.
* x64: Add x86-specific lowerings for relaxed simd
This commit builds on the prior commit and adds an array of `x86_*`
instructions to Cranelift which have semantics that match their
corresponding x86 equivalents. Translation for relaxed simd is then
additionally updated to conditionally generate different CLIF for
relaxed simd instructions depending on whether the target is x86 or not.
This means that for AArch64 no changes are made but for x86 most relaxed
instructions now lower to some x86-equivalent with slightly different
semantics than the "deterministic" lowering.
* Add libcall support for fma to Wasmtime
This will be required to implement the `f32x4.relaxed_madd` instruction
(and others) when an x86 host doesn't specify the `has_fma` feature.
* Ignore relaxed-simd tests on s390x and riscv64
* Enable relaxed-simd tests on s390x
* Update cranelift/codegen/meta/src/shared/instructions.rs
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
* Add a FIXME from review
* Add notes about deterministic semantics
* Don't default `has_native_fma` to `true`
* Review comments and rebase fixes
---------
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
2 years ago
|
|
|
|
|
|
|
fn test_directory_module(
|
|
|
|
out: &mut String,
|
|
|
|
path: impl AsRef<Path>,
|
|
|
|
strategy: &str,
|
|
|
|
) -> anyhow::Result<usize> {
|
|
|
|
let path = path.as_ref();
|
|
|
|
let testsuite = &extract_name(path);
|
|
|
|
with_test_module(out, testsuite, |out| test_directory(out, path, strategy))
|
|
|
|
}
|
|
|
|
|
|
|
|
fn test_directory(
|
|
|
|
out: &mut String,
|
|
|
|
path: impl AsRef<Path>,
|
|
|
|
strategy: &str,
|
|
|
|
) -> anyhow::Result<usize> {
|
|
|
|
let path = path.as_ref();
|
|
|
|
let mut dir_entries: Vec<_> = path
|
|
|
|
.read_dir()
|
|
|
|
.context(format!("failed to read {:?}", path))?
|
|
|
|
.map(|r| r.expect("reading testsuite directory entry"))
|
|
|
|
.filter_map(|dir_entry| {
|
|
|
|
let p = dir_entry.path();
|
|
|
|
let ext = p.extension()?;
|
|
|
|
// Only look at wast files.
|
|
|
|
if ext != "wast" {
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
// Ignore files starting with `.`, which could be editor temporary files
|
|
|
|
if p.file_stem()?.to_str()?.starts_with('.') {
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
Some(p)
|
|
|
|
})
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
dir_entries.sort();
|
|
|
|
|
|
|
|
let testsuite = &extract_name(path);
|
|
|
|
for entry in dir_entries.iter() {
|
|
|
|
write_testsuite_tests(out, entry, testsuite, strategy, false)?;
|
|
|
|
write_testsuite_tests(out, entry, testsuite, strategy, true)?;
|
|
|
|
}
|
|
|
|
|
|
|
|
Ok(dir_entries.len())
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Extract a valid Rust identifier from the stem of a path.
|
|
|
|
fn extract_name(path: impl AsRef<Path>) -> String {
|
|
|
|
path.as_ref()
|
|
|
|
.file_stem()
|
|
|
|
.expect("filename should have a stem")
|
|
|
|
.to_str()
|
|
|
|
.expect("filename should be representable as a string")
|
|
|
|
.replace(['-', '/'], "_")
|
|
|
|
}
|
|
|
|
|
|
|
|
fn with_test_module<T>(
|
|
|
|
out: &mut String,
|
|
|
|
testsuite: &str,
|
|
|
|
f: impl FnOnce(&mut String) -> anyhow::Result<T>,
|
|
|
|
) -> anyhow::Result<T> {
|
|
|
|
out.push_str("mod ");
|
|
|
|
out.push_str(testsuite);
|
|
|
|
out.push_str(" {\n");
|
|
|
|
|
|
|
|
let result = f(out)?;
|
|
|
|
|
|
|
|
out.push_str("}\n");
|
|
|
|
Ok(result)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn write_testsuite_tests(
|
|
|
|
out: &mut String,
|
|
|
|
path: impl AsRef<Path>,
|
|
|
|
testsuite: &str,
|
|
|
|
strategy: &str,
|
|
|
|
pooling: bool,
|
|
|
|
) -> anyhow::Result<()> {
|
|
|
|
let path = path.as_ref();
|
|
|
|
let testname = extract_name(path);
|
|
|
|
|
|
|
|
writeln!(out, "#[test]")?;
|
|
|
|
// Ignore when using QEMU for running tests (limited memory).
|
Implement the memory64 proposal in Wasmtime (#3153)
* Implement the memory64 proposal in Wasmtime
This commit implements the WebAssembly [memory64 proposal][proposal] in
both Wasmtime and Cranelift. In terms of work done Cranelift ended up
needing very little work here since most of it was already prepared for
64-bit memories at one point or another. Most of the work in Wasmtime is
largely refactoring, changing a bunch of `u32` values to something else.
A number of internal and public interfaces are changing as a result of
this commit, for example:
* Acessors on `wasmtime::Memory` that work with pages now all return
`u64` unconditionally rather than `u32`. This makes it possible to
accommodate 64-bit memories with this API, but we may also want to
consider `usize` here at some point since the host can't grow past
`usize`-limited pages anyway.
* The `wasmtime::Limits` structure is removed in favor of
minimum/maximum methods on table/memory types.
* Many libcall intrinsics called by jit code now unconditionally take
`u64` arguments instead of `u32`. Return values are `usize`, however,
since the return value, if successful, is always bounded by host
memory while arguments can come from any guest.
* The `heap_addr` clif instruction now takes a 64-bit offset argument
instead of a 32-bit one. It turns out that the legalization of
`heap_addr` already worked with 64-bit offsets, so this change was
fairly trivial to make.
* The runtime implementation of mmap-based linear memories has changed
to largely work in `usize` quantities in its API and in bytes instead
of pages. This simplifies various aspects and reflects that
mmap-memories are always bound by `usize` since that's what the host
is using to address things, and additionally most calculations care
about bytes rather than pages except for the very edge where we're
going to/from wasm.
Overall I've tried to minimize the amount of `as` casts as possible,
using checked `try_from` and checked arithemtic with either error
handling or explicit `unwrap()` calls to tell us about bugs in the
future. Most locations have relatively obvious things to do with various
implications on various hosts, and I think they should all be roughly of
the right shape but time will tell. I mostly relied on the compiler
complaining that various types weren't aligned to figure out
type-casting, and I manually audited some of the more obvious locations.
I suspect we have a number of hidden locations that will panic on 32-bit
hosts if 64-bit modules try to run there, but otherwise I think we
should be generally ok (famous last words). In any case I wouldn't want
to enable this by default naturally until we've fuzzed it for some time.
In terms of the actual underlying implementation, no one should expect
memory64 to be all that fast. Right now it's implemented with
"dynamic" heaps which have a few consequences:
* All memory accesses are bounds-checked. I'm not sure how aggressively
Cranelift tries to optimize out bounds checks, but I suspect not a ton
since we haven't stressed this much historically.
* Heaps are always precisely sized. This means that every call to
`memory.grow` will incur a `memcpy` of memory from the old heap to the
new. We probably want to at least look into `mremap` on Linux and
otherwise try to implement schemes where dynamic heaps have some
reserved pages to grow into to help amortize the cost of
`memory.grow`.
The memory64 spec test suite is scheduled to now run on CI, but as with
all the other spec test suites it's really not all that comprehensive.
I've tried adding more tests for basic things as I've had to implement
guards for them, but I wouldn't really consider the testing adequate
from just this PR itself. I did try to take care in one test to actually
allocate a 4gb+ heap and then avoid running that in the pooling
allocator or in emulation because otherwise that may fail or take
excessively long.
[proposal]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md
* Fix some tests
* More test fixes
* Fix wasmtime tests
* Fix doctests
* Revert to 32-bit immediate offsets in `heap_addr`
This commit updates the generation of addresses in wasm code to always
use 32-bit offsets for `heap_addr`, and if the calculated offset is
bigger than 32-bits we emit a manual add with an overflow check.
* Disable memory64 for spectest fuzzing
* Fix wrong offset being added to heap addr
* More comments!
* Clarify bytes/pages
3 years ago
|
|
|
if ignore(testsuite, &testname, strategy) {
|
|
|
|
writeln!(out, "#[ignore]")?;
|
Run some tests in MIRI on CI (#6332)
* Run some tests in MIRI on CI
This commit is an implementation of getting at least chunks of Wasmtime
to run in MIRI on CI. The full test suite is not possible to run in MIRI
because MIRI cannot run Cranelift-produced code at runtime (aka it
doesn't support JITs). Running MIRI, however, is still quite valuable if
we can manage it because it would have trivially detected
GHSA-ch89-5g45-qwc7, our most recent security advisory. The goal of this
PR is to select a subset of the test suite to execute in CI under MIRI
and boost our confidence in the copious amount of `unsafe` code in
Wasmtime's runtime.
Under MIRI's default settings, which is to use the [Stacked
Borrows][stacked] model, much of the code in `Instance` and `VMContext`
is considered invalid. Under the optional [Tree Borrows][tree] model,
however, this same code is accepted. After some [extremely helpful
discussion][discuss] on the Rust Zulip my current conclusion is that
what we're doing is not fundamentally un-sound but we need to model it
in a different way. This PR, however, uses the Tree Borrows model for
MIRI to get something onto CI sooner rather than later, and I hope to
follow this up with something that passed Stacked Borrows. Additionally
that'll hopefully make this diff smaller and easier to digest.
Given all that, the end result of this PR is to get 131 separate unit
tests executing on CI. These unit tests largely exercise the embedding
API where wasm function compilation is not involved. Some tests compile
wasm functions but don't run them, but compiling wasm through Cranelift
in MIRI is so slow that it doesn't seem worth it at this time. This does
mean that there's a pretty big hole in MIRI's test coverage, but that's
to be expected as we're a JIT compiler after all.
To get tests working in MIRI this PR uses a number of strategies:
* When platform-specific code is involved there's now `#[cfg(miri)]` for
MIRI's version. For example there's a custom-built "mmap" just for
MIRI now. Many of these are simple noops, some are `unimplemented!()`
as they shouldn't be reached, and some are slightly nontrivial
implementations such as mmaps and trap handling (for native-to-native
function calls).
* Many test modules are simply excluded via `#![cfg(not(miri))]` at the
top of the file. This excludes the entire module's worth of tests from
MIRI. Other modules have `#[cfg_attr(miri, ignore)]` annotations to
ignore tests by default on MIRI. The latter form is used in modules
where some tests work and some don't. This means that all future test
additions will need to be effectively annotated whether they work in
MIRI or not. My hope though is that there's enough precedent in the
test suite of what to do to not cause too much burden.
* A number of locations are fixed with respect to MIRI's analysis. For
example `ComponentInstance`, the component equivalent of
`wasmtime_runtime::Instance`, was actually left out from the fix for
the CVE by accident. MIRI dutifully highlighted the issues here and
I've fixed them locally. Some locations fixed for MIRI are changed to
something that looks similar but is subtly different. For example
retaining items in a `Store<T>` is now done with a Wasmtime-specific
`StoreBox<T>` type. This is because, with MIRI's analyses, moving a
`Box<T>` invalidates all pointers derived from this `Box<T>`. We don't
want these semantics, so we effectively have a custom `Box<T>` to suit
our needs in this regard.
* Some default configuration is different under MIRI. For example most
linear memories are dynamic with no guards and no space reserved for
growth. Settings such as parallel compilation are disabled. These are
applied to make MIRI "work by default" in more places ideally. Some
tests which perform N iterations of something perform fewer iterations
on MIRI to not take quite so long.
This PR is not intended to be a one-and-done-we-never-look-at-it-again
kind of thing. Instead this is intended to lay the groundwork to
continuously run MIRI in CI to catch any soundness issues. This feels,
to me, overdue given the amount of `unsafe` code inside of Wasmtime. My
hope is that over time we can figure out how to run Wasm in MIRI but
that may take quite some time. Regardless this will be adding nontrivial
maintenance work to contributors to Wasmtime. MIRI will be run on CI for
merges, MIRI will have test failures when everything else passes,
MIRI's errors will need to be deciphered by those who have probably
never run MIRI before, things like that. Despite all this to me it seems
worth the cost at this time. Just getting this running caught two
possible soundness bugs in the component implementation that could have
had a real-world impact in the future!
[stacked]: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md
[tree]: https://perso.crans.org/vanille/treebor/
[discuss]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Tree.20vs.20Stacked.20Borrows.20.26.20a.20debugging.20question
* Update alignment comment
2 years ago
|
|
|
} else {
|
|
|
|
writeln!(out, "#[cfg_attr(miri, ignore)]")?;
|
|
|
|
}
|
|
|
|
|
|
|
|
writeln!(
|
|
|
|
out,
|
|
|
|
"fn r#{}{}() {{",
|
|
|
|
&testname,
|
|
|
|
if pooling { "_pooling" } else { "" }
|
|
|
|
)?;
|
|
|
|
writeln!(out, " let _ = env_logger::try_init();")?;
|
|
|
|
writeln!(
|
|
|
|
out,
|
|
|
|
" crate::wast::run_wast(r#\"{}\"#, crate::wast::Strategy::{}, {}).unwrap();",
|
|
|
|
path.display(),
|
|
|
|
strategy,
|
|
|
|
pooling,
|
|
|
|
)?;
|
|
|
|
writeln!(out, "}}")?;
|
|
|
|
writeln!(out)?;
|
|
|
|
Ok(())
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Ignore tests that aren't supported yet.
|
|
|
|
fn ignore(testsuite: &str, testname: &str, strategy: &str) -> bool {
|
|
|
|
assert_eq!(strategy, "Cranelift");
|
|
|
|
|
|
|
|
// This is an empty file right now which the `wast` crate doesn't parse
|
|
|
|
if testname.contains("memory_copy1") {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
match env::var("CARGO_CFG_TARGET_ARCH").unwrap().as_str() {
|
|
|
|
"s390x" => {
|
s390x: Implement full SIMD support (#4427)
This adds full support for all Cranelift SIMD instructions
to the s390x target. Everything is matched fully via ISLE.
In addition to adding support for many new instructions,
and the lower.isle code to match all SIMD IR patterns,
this patch also adds ABI support for vector types.
In particular, we now need to handle the fact that
vector registers 8 .. 15 are partially callee-saved,
i.e. the high parts of those registers (which correspond
to the old floating-poing registers) are callee-saved,
but the low parts are not. This is the exact same situation
that we already have on AArch64, and so this patch uses the
same solution (the is_included_in_clobbers callback).
The bulk of the changes are platform-specific, but there are
a few exceptions:
- Added ISLE extractors for the Immediate and Constant types,
to enable matching the vconst and swizzle instructions.
- Added a missing accessor for call_conv to ABISig.
- Fixed endian conversion for vector types in data_value.rs
to enable their use in runtests on the big-endian platforms.
- Enabled (nearly) all SIMD runtests on s390x. [ Two test cases
remain disabled due to vector shift count semantics, see below. ]
- Enabled all Wasmtime SIMD tests on s390x.
There are three minor issues, called out via FIXMEs below,
which should be addressed in the future, but should not be
blockers to getting this patch merged. I've opened the
following issues to track them:
- Vector shift count semantics
https://github.com/bytecodealliance/wasmtime/issues/4424
- is_included_in_clobbers vs. link register
https://github.com/bytecodealliance/wasmtime/issues/4425
- gen_constant callback
https://github.com/bytecodealliance/wasmtime/issues/4426
All tests, including all newly enabled SIMD tests, pass
on both z14 and z15 architectures.
2 years ago
|
|
|
// FIXME: These tests fail under qemu due to a qemu bug.
|
|
|
|
testname == "simd_f32x4_pmin_pmax" || testname == "simd_f64x2_pmin_pmax"
|
|
|
|
}
|
|
|
|
|
|
|
|
"riscv64" => {
|
|
|
|
if testname.contains("memory_multi") || testsuite.contains("relaxed_simd") {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The memory64 testsuite has a single SIMD test that we don't pass yet.
|
|
|
|
if testname == "simd" && testsuite == "memory64" {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
let known_failure = [
|
|
|
|
"almost_extmul",
|
|
|
|
"canonicalize_nan",
|
|
|
|
"cvt_from_uint",
|
|
|
|
"issue4807",
|
|
|
|
"issue_3327_bnot_lowering",
|
|
|
|
"load_splat_out_of_bounds",
|
|
|
|
"replace_lane_preserve",
|
|
|
|
"simd_align",
|
|
|
|
"simd_bit_shift",
|
|
|
|
"simd_bitwise",
|
|
|
|
"simd_boolean",
|
|
|
|
"simd_conversions",
|
|
|
|
"simd_f32x4",
|
|
|
|
"simd_f32x4_cmp",
|
|
|
|
"simd_f32x4_pmin_pmax",
|
|
|
|
"simd_f32x4_rounding",
|
|
|
|
"simd_f64x2",
|
|
|
|
"simd_f64x2_cmp",
|
|
|
|
"simd_f64x2_pmin_pmax",
|
|
|
|
"simd_f64x2_rounding",
|
|
|
|
"simd_i16x8_arith2",
|
|
|
|
"simd_i16x8_cmp",
|
|
|
|
"simd_i16x8_extadd_pairwise_i8x16",
|
|
|
|
"simd_i16x8_extmul_i8x16",
|
|
|
|
"simd_i16x8_q15mulr_sat_s",
|
|
|
|
"simd_i16x8_sat_arith",
|
|
|
|
"simd_i32x4_arith2",
|
|
|
|
"simd_i32x4_cmp",
|
|
|
|
"simd_i32x4_dot_i16x8",
|
|
|
|
"simd_i32x4_extadd_pairwise_i16x8",
|
|
|
|
"simd_i32x4_extmul_i16x8",
|
|
|
|
"simd_i32x4_trunc_sat_f32x4",
|
|
|
|
"simd_i32x4_trunc_sat_f64x2",
|
|
|
|
"simd_i64x2_arith2",
|
|
|
|
"simd_i64x2_cmp",
|
|
|
|
"simd_i64x2_extmul_i32x4",
|
|
|
|
"simd_i8x16_arith2",
|
|
|
|
"simd_i8x16_cmp",
|
|
|
|
"simd_i8x16_sat_arith",
|
|
|
|
"simd_int_to_int_extend",
|
|
|
|
"simd_lane",
|
|
|
|
"simd_load",
|
|
|
|
"simd_load16_lane",
|
|
|
|
"simd_load32_lane",
|
|
|
|
"simd_load64_lane",
|
|
|
|
"simd_load8_lane",
|
|
|
|
"simd_load_extend",
|
|
|
|
"simd_load_zero",
|
|
|
|
"simd_splat",
|
|
|
|
"v128_select",
|
|
|
|
]
|
|
|
|
.contains(&testname);
|
|
|
|
|
|
|
|
known_failure
|
|
|
|
}
|
|
|
|
|
|
|
|
_ => false,
|
|
|
|
}
|
|
|
|
}
|