This patch updates `test-wasi-import-object` to test the new
`wasmer_wasi_get_version` &
`wasmer_wasi_generate_import_object_for_version` functions, and the
new `Version` type.
This patch introduces 2 new functions:
* `wasmer_wasi_generate_import_object_for_version` and
* `wasmer_wasi_get_version`.
It mimics the current API provided by `wasmer_wasi`, nothing fancy
here. It's just a regular port to C/C++.
Because `wasmer_wasi::get_wasi_version` returns an option, and in
order to simplify the C/C++ API, `wasmer_wasi_get_version` can return
`Version::Unknown` in case of an error. It's up to the user to check
the version is valid (i.e. not unknown).
1029: feat(wasi) Add the “floating” `WasiVersion::Latest` version. r=Hywan a=Hywan
In addition to `Snapshot0` and `Snapshot1`, I believe it is an
interesting API to provide the `Latest` version, so that the user can
write:
```rust
generate_import_object_for_version(WasiVersion::Latest, …);
```
This is a way to ensure that modules will run only if they come with
the latest WASI version (in case of security issues for instance), by
just updating the runtime.
Note that it can be dangerous if not used carefully, but we assume the
user knows what it does by sticking on a specific “floating” version.
Also note that the `Latest` version is never returned by any API. It
is provided only by the user.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
In strict mode, `get_wasi_version` uses the previous behavior, i.e. it
checks that there is only one namespace for all imports, and that this
namespace is a WASI namespace (and uses it to find the WASI version).
In non-strict mode, `get_wasi_version` checks that at least one WASI
namespace exists (and uses it to find the WASI version).
By default, `is_wasi_module` uses the non-strict mode.
1035: Fix/quiet some rustc warnings. r=nlewycky a=nlewycky
No functionality change.
Remaining warnings are either dead code in examples/parallel-guest, or due to macros in typed_func.rs for which removing the "extra" parentheses breaks the build.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
1034: When modifying the value, also update its ExtraInfo. r=nlewycky a=nlewycky
Fixes a debug_assert! on python3.7 and rustpython in wapm.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
1031: Improve portability of code by using c_char r=MarkMcCaskey a=MarkMcCaskey
This PR makes emscripten compile on ARM with an up to date nightly compiler
Co-authored-by: Mark McCaskey <mark@wasmer.io>
1022: Add caching support for Singlepass backend. r=losfair a=losfair
This PR adds caching support for the Singlepass backend.
- [x] Implementation
- [x] AArch64 test
Co-authored-by: losfair <zhy20000919@hotmail.com>
Co-authored-by: Heyang Zhou <zhy20000919@hotmail.com>
In addition to `Snapshot0` and `Snapshot1`, I believe it is an
interesting API to provide the `Latest` version, so that the user can
write:
```rust
generate_import_object_for_version(WasiVersion::Latest, …);
```
This is a way to ensure that modules will run only if they come with
the latest WASI version (in case of security issues for instance), by
just updating the runtime.
Note that it can be dangerous if not used carefully, but we assume the
user knows what it does by sticking on a specific “floating” version.
Also note that the `Latest` version is never returned by any API. It
is provided only by the user.
If a module has multiple import namespaces, `get_wasi_version` is
broken because it assumes a module must only have a single namespace.
This patch fixes it by a slower `get_wasi_version` function, but a
correct one. As soon as the `wasi_unstable` or
`wasi_snapshot_preview1` namespace is met, `get_wasi_version` maps it
to the respective `WasiVersion` variant. It assumes however that a
module must hold a unique WASI version.
1004: Adapt backend usage depending on wasm file executed r=MarkMcCaskey a=d0iasm
Adapt backend usage depending on wasm file executed in issue #998.
Close#998
# Description
Add `auto` backend into a runtime-core and use it as a default backend.
The `auto` backend is equivalent to:
* singlepass if singlepass is enabled and the wasm file size is larger than 10MiB, or singlepass is enable and the target architecture is aarch64.
* cranelift otherwise.
Co-authored-by: Asami Doi <doiasami1219@gmail.com>
1019: Update llvm backend to work with latest inkwell. r=nlewycky a=nlewycky
cargo update to pick up latest inkwell branch commit.
Add lifetime annotations to Module which now takes a lifetime.
Add <'ctx> across CtxType and Intrinsics. Remove it from reference bindings.
Use ManuallyDrop to ensure that context's members are dropped before the Context.
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Co-authored-by: Nick Lewycky <nick@wasmer.io>
cargo update to pick up latest inkwell branch commit.
Add lifetime annotations to Module which now takes a lifetime, and more lifetime annotations across intrinsics.rs.
Add <'ctx> to missing places in CtxType and Intrinsics. Remove it from reference bindings.
Use ManuallyDrop to ensure that context's members are dropped before the Context.
Co-authored-by: Mark McCaskey <mark@wasmer.io>
1020: Turn a few more assert!s that should never fire into debug_assert!s. r=nlewycky a=nlewycky
These are here to protect against errors when refactoring more than anything else.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
1006: fix 1005 panic sub overflow r=MarkMcCaskey a=pventuzelo
# Description
Fix issue https://github.com/wasmerio/wasmer/issues/1005
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Patrick Ventuzelo <ventuzelo.patrick@gmail.com>
Co-authored-by: Patrick Ventuzelo <9038181+pventuzelo@users.noreply.github.com>
934: In LLVM backend, track which floats are guaranteed to be arithmetic, which makes the canonicalization a no-op. r=nlewycky a=nlewycky
# Description
This is a reimplementation of the patch in PR #651.
Extend state.rs ExtraInfo to track more information about floats. In addition to tracking whether the value has a pending canonicalization of NaNs, also track whether the value is known to be arithmetic (which includes infinities, regular values, and non-signalling NaNs (aka. "arithmetic NaNs" in the webassembly spec)). When the value is arithmetic, the correct sequence of operations to canonicalize the value is a no-op. Therefore, we create a lattice where pending+arithmetic=arithmetic.
Also, this extends the tracking to track all values, including non-SIMD integers. That's why there are more places where pending canonicalizations are applied.
Looking at c-wasm-simd128-example, this provides no performance change to the non-SIMD case (takes 58s on my noisy dev machine). The SIMD case drops from 46s to 29s.
# Review
- [ ] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Nick Lewycky <nick@wasmer.io>
Fix a bug in Operator::Select and add a comment to explain the intention.
Use derived default for ExtraInfo.
Make ExtraInfo associated functions const.
Turn two asserts into debug_asserts.
We want to ignore the incoming pending NaN state (since the pending will propagate to the output if there was one on the input), and we want to add a new pending NaN state if we can (that is to say, if it isn't cancelled out by both inputs having arithmetic state). Do this by discarding the pending states on the inputs, intersecting them (to keep only the arithmetic state), then union in a pending nan state (which might do nothing, if it's arithmetic).
If the above sounds confusing, keep in mind that when a value is arithmetic, the act of performing the "NaN canonicalization" is a no-op. Thus, being arithmetic cancels out pending NaN states.
Unfortunately, this is quite buggy. For something as simple as F32Sub, to combine two ExtraInfos, we want to add a new pending_f32_nan(), unless both of the inputs are arithmetic_f32(). In this commit, we incorrectly calculate that we don't need a pending_f32_nan if either one of the inputs was arithmetic_f32().
It seemed like a good idea at the time, but in practice we discard the extra info all or almost all of the time.
This also introduces a new bug. In an operation like multiply, it's valid to multiply two values, one with a pending NaN and one without. As written, in the SIMD case (because of the two kinds of pending in play), we assert.
