forked from bytecodealliance/wasmtime
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge with upstream #227
Merged
Merged
Merge with upstream #227
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…9254) This commit fixes a fuzz bug that cropped up over the weekend where a config was being created with signals-based traps disabled and spectre mitigations enabled which are incompatible configurations at this time. The fix is to apply the "make this `Config` consistent" logic in another location.
* Remove WasmtimeSystemV call conv It is no longer used by Wasmtime * Remove CallConv::extends_* methods They all match only a single call conv anyway. * Avoid isa:: prefix for referencing CallConv where possible * Update callconv list in the clif ir reference * Use push_non_formal where expected
…nds (bytecodealliance#9258) Unlike x86_64 and some other architectures where large structs are passed at fixed stack offsets, necessitating special Cranelift support, arm64, riscv64 and s390x pass them using regular pointer arguments that can trivially be implemented by frontends. The current implementation of StructArgument on arm64 and riscv64 uses fixed stack offsets just like on x86_64, which is incorrect as per the ABI documentation. In other words any correct frontend already had to avoid StructArgument on arm64 and riscv64 anyway. For s390x it is correctly implemented but unnecessary and taints even non-s390x specific code.
…e#9260) Consolidate all `i31ref` special casing into the `translate_{read,write}_gc_reference` methods, which already emit more or less inline GC barriers depending on the reference's heap type, so it makes sense to also handle `i31ref` there. Co-authored-by: Trevor Elliott <[email protected]>
…ce#9257) This commit updates the defaults of `PoolingAllocationConfig` to allow unlimited core instances/memories/tables per component instead of the previous default of 20. The limits here are somewhat restrictive and more tailored for high-scale use cases which aren't always the best defaults for a general purpose tool like the `wasmtime` CLI. The CLI for example uses the pooling allocator by default with `serve` and this helps accept a wider breadth of components by default instead of artificially limiting the shape of input components.
…odule` (bytecodealliance#9261) Because it returns the `wasmtime_environ::Module`. This paves the way for a new method to get the `wasmtime::Module`.
* Add async tracing versions of the component-macro tests * Use instrument when generating async call functions with tracing * Update tests
…ealliance#9262) * wit-bindgen: Don't trace values containing lists by default. `list` values in Wit interfaces can represent things like HTTP bodies which can be very large. To enable tracing without spamming logfiles with all this data, put printing of values containing `list`s behind a separate `verbose_tracing` option. This is a coarse-grained approach; but it seems like a pretty good default for tracing, and enabling full tracing when one needs it is straightforward. In the future, we may want to refine the option by implementing the `Valuable` trait and using `tracing::field::valuable`, which could allow us to do things like print non-`list` fields of records that otherwise contain `list`s. * Use `option_type_contains_lists` more. * Hook up `verbose_tracing` to the macro. * Update expected outputs for tests.
…9269) With table64 support it's now possible that the number of desired table elements can overflow the address space when multiplied by the size of a pointer, so account for this when handling resource limits while fuzzing.
And do some minor refactors to the DRC collector to build other allocation methods on top of that one internally. This method will be used in forthcoming PRs implementing the `struct.new[_default]` instructions, where a libcall does the actual allocation, but Wasm code performs field initialization inline.
…d with a `wasmtime::runtime::vm::Instance` (bytecodealliance#9268)
…ce#9273) Copyright (c) 2024, Arm Limited. Signed-off-by: Karl Meakin <[email protected]>
…iance#9267) * Add a couple assertions about misuse of StructReturn * Move STACK_ARG_RET_SIZE_LIMIT enforcement to SigSet::from_func_sig * Slightly simplify SigSet::abi_sig_for_sig_ref * Pass the return area pointer as first argument on sysv and fastcall The SystemV and WindowsFastcall calling conventions expect the return area pointer as first argument on most archs, while the Tail and Winch calling conventions expect it as last argument on all archs. On arm64 x8 is used as return area pointer register. S390x already handled everything correctly. * Explicitly annotate call conv to use in s390x user_stack_maps test * Fix windows_fastcall abi * Improve Debug impls for Reg and ValueRegs
* Implement the `struct.*` GC instructions This commit implements the `struct.*` instructions for the GC proposal. These instructions allow allocating new structs and getting and setting their fields. The implemented instructions are: * `struct.new` * `struct.new_default` * `struct.get` * `struct.get_s` * `struct.get_u` * `struct.set` The `struct.new*` instructions are also allowed in constant expressions, but support for that is not yet implemented. Co-Authored-By: Trevor Elliott <[email protected]> * Fill in TODO doc comment * Dedupe gc-disabled messages * Fix warnings in no-gc builds --------- Co-authored-by: Trevor Elliott <[email protected]>
…e#9278) * Make `gc_compiler` return a result This way we don't even need to stub out a no-op GC compiler when GC is disabled at compile time. * Move DRC-specific GC compiler bits to its own submodule This lets us differentiate between common code that is needed for any GC compiler implementation and DRC-specific code. * Stop manually forwarding proxying the GC compiler interface Just `pub use imp::*` instead
) * Rename the `wasmtime::runtime::vm::Store` trait to `VMStore` Purely mechanical. * Add `StoreOpaque` accessors to the `VMStore` trait * Make `dyn VMStore` deref to `StoreOpaque` * Remove the `VMStore::vmruntime_limits` method * Remove the `VMStore::epoch_ptr` method * Rename `VMStore::gc_store` to `unwrap_gc_store_mut` Will make removing the trait method easier. * Remove `VMStore`'s `GcStore`-related methods * cargo fmt * Fix build with shared memory disabled
The only thing it does over Context::compile is writing the machine code to a Vec specified by the user. Every user of Context::compile_and_emit in Cranelift didn't actually need ownership over the machine code bytes and thus would have been able to use Context::compile instead to avoid an unnecessary allocation. This commit moves all in-tree users of compile_and_emit to compile and additionally to avoid other users adding an unnecessary allocation as they though it to be necessary, this commit additionally deprecates compile_and_emit.
The alignment for stackslots was commputed wrongly, because the end of the slot was being aligned instead of the beginning. This effectively meant that the _next_ stackslot was being aligned on the alignment of the current slot.
…iance#9284) * Remove unused isle_prelude_caller_methods macro argument * Move gen_return_call into isle_prelude_caller_methods! This reduces duplication between backends a bit.
Copyright (c) 2024, Arm Limited. Signed-off-by: Karl Meakin <[email protected]>
With bytecodealliance#9266 Wasmtime should have full support for this platform. While not tested in CI it can still be useful to build artifacts nonetheless in case users are interested. prtest:full
…C instructions (bytecodealliance#9282) * Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions * fix no-gc builds * wrap const evaluation in `AutoAssertNoGc` * add assertions that we access `VMGcRef`s in native-endian * fix an endian mismatch bug between compiled wasm code and host code
* Introduce the `wasmtime::EqRef` type This commit introduces the `wasmtime::EqRef` type, which corresponds to Wasm's `(ref eq)` type, and statically represents Wasm references that can be tested for equality. * fix no-gc builds
…dealliance#9286) * Remove the `wasmtime::runtime::vm::ModuleInfo` trait This harkens back to the `wasmtime` vs `wasmtime-runtime` crate split. We can simply use `wasmtime::Module` these days. * Rename `wasmtime::runtime::vm::ModuleInfoLookup::lookup` to `lookup_module_by_pc` This will make removing `ModuleInfoLookup` easier in subsequent commits. * Remove the `ModuleInfoLookup` trait This harkens back to the `wasmtime` vs `wasmtime-runtime` crate split. We can simply use the `ModuleRegistry` directly now. * cargo fmt
…ea ptr (bytecodealliance#9287) * Make the Tail call conv follow the system call conv for the return area ptr And for Winch make it follow the system call conv on all targets except aarch64 where the first regular argument register is used instead of the designated register. * Fix review comments
…nce#9291) * Update some dependencies on their major version tracks Update some deps in our `Cargo.toml` from crates.io that were behind their latest semver-compatible tracks. No major motivation at this time other than keeping up-to-date. * Fix compile on arm64 windows
…#9292) This commit derives the operand size from `ABI::word_bytes()` in order to zero the given register rather than hardcoding it as a 32-bit size operand. The motivation for this commit is mainly avoiding hardcoding operand sizes in Winch's emission layer where possible, especially in the MacroAssembler.
* Lower conditional traps in backend Instead of legalizing `trapz` and `trapnz` in the mid-end, we now take them all the way to the backend. This allows us to GVN them and remove redundant trap checks. This also allows us to avoid creating new blocks in the legalizer and otherwise invalidating the control-flow graph. * Lower `trap[n]z` clif instructions in Pulley * Update disas tests --------- Co-authored-by: Nick Fitzgerald <[email protected]>
Helps deduplicate wasm-tools deps in the workspace.
This commit introduces a REAME.md in `winch`s directory with some high-level documentation which was long overdue.
Winch on x64_64 can _almost_ be considered Tier 2, however we are still missing support for some Tier 1 WebAssembly proposals.
To precisely match the Wasm spec tests, we would also need `NullStructRef` and `NullArrayRef`, etc... This is not practical, given the encoding space we have available. We are already matching expected "null FOO reference" trap messages when running the spec tests to our own "null reference" messages, so we can do that for `i31`s as well.
This is needed in the implementation of Wasm GC's array instructions.
…alliance#9288) * feat: bindgen: add support for multiple wit paths * expanded tests * fmt --------- Co-authored-by: Lochlan Wansbrough <>
…iance#9302) * Add `-Wasync-stack-size`, automatically configure it too Recently the `wasmtime` CLI switched from sync to async to handle interrupting host APIs in WASI. Previously the CLI provided no means to configure the async stack size, however, which now means that when increasing the max wasm stack the CLI prints an error that cannot be resolved about the wasm stack being larger than the async stack. This commit fixes this issue by both adding a configuration option for the async stack size and additionally automatically increasing the async stack size when only the wasm stack size is provided. Closes bytecodealliance#9298 * Fix feature-gated build
* Update to cap-std 3.3.0. cap-std 3.3.0 contains bytecodealliance/cap-std#366, which fixes bytecodealliance#9272, which is about the handling of `..` in symlink destinations. * Add wildcard vet of pulley --------- Co-authored-by: Alex Crichton <[email protected]>
@frank-emrich I am going to merge this even though the performance regression monitor reports failure. It probably shouldn't fail due to a regression but rather report it directly here on the PR as a comment. But we can look into building such a bot later. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.