917: feat(runtime-core) Host function without a `vm::Ctx` argument r=Hywan a=Hywan
Extracted from https://github.com/wasmerio/wasmer/pull/882.
~Includes https://github.com/wasmerio/wasmer/pull/916. Must not be merged until #916 lands in `master`.~
~If you want to compare only the different commits, see https://github.com/Hywan/wasmer/compare/feat-runtime-core-tests...Hywan:feat-runtime-core-host-function-without-vmctx?expand=1.~
This patch updates the `ExternalFunction` implementation to support host functions (aka imported functions) without having an explicit `vm::Ctx` argument.
It is thus possible to write:
```rust
fn add_one(x: i32) -> i32 {
x + 1
}
let import_object = imports! {
"env" => {
"add_one" => func!(add_one);
},
};
```
The previous form is still working though:
```rust
fn add_one(_: &mut vm::Ctx, x: i32) -> i32 {
x + 1
}
```
The backends aren't modified. It means that the pointer to `vm::Ctx` is still inserted in the stack, but it is not used when the function doesn't need it.
We thought this is an acceptable trade-off.
About the C API. It has not check to ensure the type signature. Since the pointer to `vm::Ctx` is always inserted, the C API can digest host functions with or without a `vm::Ctx` argument. The C API uses [the `Export` + `FuncPointer` API](cf5b3cc09e/lib/runtime-c-api/src/import/mod.rs (L630-L653)) instead of going through the `Func` API (which is modified by this API), which is only possible since the C API only receives an opaque function pointer. Conclusion is: We can't ensure anything on the C side, but it will work with or without the `vm::Ctx` argument in theory.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
915: fix(runtime-core) Share the definition of `Trampoline` across all the backends r=Hywan a=Hywan
Extracted from https://github.com/wasmerio/wasmer/pull/882.
This patch updates all the backends to use the definition of
`Trampoline` as defined in the `wasmer_runtime_core::typed_func`
module. That way, there is no copy of that type, and as such, it is
easier to avoid regression (a simple `cargo check` does the job).
This patch also formats the `use` statements in the updated files.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
This patch allows host functions to get a signature without an
explicit `vm::Ctx` argument.
It is for Rust only. The C API receives a function pointer and has no
clue whether a `vm::Ctx` argument is present or not, so it assumes it
is always declared.
From the backend point of view, the pointer to `vm::Ctx` is always
inserted in the stack, but it is not used by the function when the
argument is absent.
916: feat(runtime-core-tests) Introduce the new `wasmer-runtime-core-tests` crate r=Hywan a=Hywan
Extracted from https://github.com/wasmerio/wasmer/pull/882.
This non-publishable new crate contains a test suite for the
`wasmer-runtime-core` crate. So far, the test suite is rather small,
but it aims to be extended in a close future.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
This non-publishable new crate contains a test suite for the
`wasmer-runtime-core` crate. So far, the test suite is rather small,
but it aims to be extended in a close future.
This patch updates all the backends to use the definition of
`Trampoline` as defined in the `wasmer_runtime_core::typed_func`
module. That way, there is no copy of that type, and as such, it is
easier to avoid regression (a simple `cargo check` does the job).
This patch also formats the `use` statements in the updated files.
914: Fix bug in getting a Memory from export in C API r=Hywan a=MarkMcCaskey
I believe this fixes the non-deterministic crashing on OSX in `go-ext-wasm`
Co-authored-by: Mark McCaskey <mark@wasmer.io>
856: Add WASI support to C API r=MarkMcCaskey a=MarkMcCaskey
This is an additive change (with one unrelated clean up of `*mut ptr -> *const ptr`). It exposes the functions to get a WASI import object. It also implements a function on import object to get an `import` with namespace and name.
These changes should be okay to ship now, we can follow up to finish adding methods to ImportObject on the C API side and start migrating away from `*imports`.
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
Co-authored-by: Mark McCaskey <markmccaskey@users.noreply.github.com>
Co-authored-by: nlewycky <nick@wasmer.io>
910: Use getrandom instead of rand r=MarkMcCaskey a=newpavlov
Closes#909
Note: I am reusing `__WASI_EIO` as an error code to denote a potential OS RNG failure.
Co-authored-by: newpavlov <newpavlov@gmail.com>
Co-authored-by: Artyom Pavlov <newpavlov@gmail.com>
883: For floating point operations, allow inputs to be arbitrary, including SNaNs. r=nlewycky a=nlewycky
# Description
For floating point operations, allow inputs to be arbitrary, including SNaNs.
Instead of ensuring inputs are canonical NaNs on every operation, we tag outputs as pending such a canonicalization check, so that a sequence of computations 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. Since a canonicalization may change the bit patterns in a way that transforms one non-NaN to another non-NaN in the next subsequent instructions interpretation, most SIMD functions apply pending canonicalizations to their inputs, even the integer SIMD operations.
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Nick Lewycky <nick@wasmer.io>
Co-authored-by: nlewycky <nick@wasmer.io>
Co-authored-by: Syrus Akbary <me@syrusakbary.com>
901: Set target triple and datalayout when creating the LLVM module. r=nlewycky a=nlewycky
We were giving LLVM a triple and datalayout only when producing native code from the LLVM IR. With this change, we tell LLVM as early as possible so that the entire optimization stack knows that it's safe to use target-specific constructs (including target intrinsics `@llvm.x86.sse2.ucomieq.sd`) as well as cost models (for autovectorization) and knowing the bitwidth of the registers so that we can know it's profitable to eliminate redundant extend/truncate casts.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
904: Use getelementptr instruction instead of int_to_ptr and ptr_to_int. r=nlewycky a=nlewycky
The main part of this change is that we no longer turn pointers into integers to do arithmetic on them, then turn them back into pointers. Doing so is a signal to LLVM that it should not attempt to analyze the provenance of the pointers, disabling some optimizations. Using getelementptr allows us to perform arithmetic on pointers while keeping them in pointer types, which LLVM can then analyze.
Most of the textual change is a refactoring to reorder the operations. Previously the bounds checking and determining of the base and bounds were combined because you could put both into the same match, since both actions are performed differently depending on whether the memory is static or dynamic. In this case, we simply check the type twice and do two different things, with comments labelling the steps.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
ptr_to_int and int_to_ptr are not treated the same as type-safe pointer operations. LLVM intentionally performs fewer optimizations to code using the former as compared with the latter. We don't need that in our code, standard pointer optimizations are safe for us.
902: Insert allocas as a contiguous block at the top of the entry block. r=syrusakbary a=nlewycky
This minimizes the chance we accidentally get categorized as having a dynamic alloca.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
