Changes in multiple-array-get.wat

7e0331c2 - Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)

Wed, 11 Feb 2026 23:43:29 +0000

Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)* Debugging: refactor stack frame cursor into frame handle abstraction.This addresses some of the issues described #12486: we need the abilityto keep a handle to a stack frame as long as execution is frozen, andkeep multiple of these handles around, alongside the `Store`, withoutany handle directly holding a borrow of the store.The frame handles work by means of an "execution version" scheme: theidea is that whenever any execution resumes in a given store, allhandles to existing frames could be invalidated, but if no suchexecution occurs, all handles should still be valid. A tuple of(globally unique for process lifetime) store ID, and execution versionwithin that store, should be sufficient to uniquely identify anyfrozen-stack period during execution. This accomplishes cheap handleinvalidation without the need to track existing handles.This PR also implements a cache of parsed frame-table data. Previouslythis was lazily parsed by the cursor as it walked up a stack, but withmultiple handles hanging around, and with handles meant to be cheap tohold and clone, and with handles being invalidated eagerly, it makesmuch more sense to persist this parsed metadata at the `Store` level.(It cannot persist at the `Engine` level because PCs are local perstore.)* Re-bless disas tests (offsets in VMStoreContext changed).* Handle invalidation tests.* Review comments, and make API return `Result`s rather than panic'ing on stale handles.* Review feedback.* Doc-comment link fix.* Review feedback.* cfg-gate Activation method to `debug` feature only.* Fix unused-import warning in no-debug cfg.* Fix doc link (again, after rename from latest feedback). List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat

b856261d - refactor recursive reentrance checks (#12349)

Wed, 14 Jan 2026 22:27:49 +0000

refactor recursive reentrance checks (#12349)* refactor recursive reentrance checksThis commit makes a few changes related to recursive reentrance checks, instancepoisoning, etc.:- Implements the more restrictive lift/lower rules described in https://github.com/WebAssembly/component-model/pull/589 such that a component instance may not lower a function lifted by one of its ancestors, nor vice-versa. Any such lower will result in a fused adapter which traps unconditionally, preventing guest-to-guest recursive reentrance without requiring data flow analysis. - Note that this required updating several WAST tests which were violating the new rule, including some in the `tests/component-model` Git submodule, which I've updated. - This is handled entirely in the `fact` module now; I've removed the `AlwaysTrap` case previously handled by `wasmtime-cranelift`.- Removes `FLAG_MAY_ENTER` from `InstanceFlags`. It is no longer needed for guest-to-guest calls due to the above, and for guest-to-host-to-guest calls we can rely on either `FLAG_NEEDS_POST_RETURN` for sync-lifted functions or the `GuestTask` call stack for async-lifted functions.- Adds a `StoreOpaque::trapped` field which is set when _any_ instance belonging to that store traps, at which point the entire store is considered poisoned, meaning no instance belonging to it may be entered. This prevents indeterminant concurrent task state left over from the trapping instance from leaking into other instances.Note that this does _not_ include code to push and pop `GuestTask` instances forguest-to-guest sync-to-sync calls, nor for host-to-guest calls using e.g. thesynchronous `Func::call` API, so certain intrinsics which expect a `GuestTask`to be present such as `backpressure.inc` will still fail in such cases. I'lladdress that in a later PR.Also note that I made a small change to `wasmtime-wit-bindgen`, adding a `Send`bound on the `T` type parameter for `store | async` functions. This allowed meto recursively call `{Typed}Func::call_concurrent` from inside a host function,and it doesn't have any downsides AFAICT.Fixes #12128* bless bindgen expansions* bless disas tests* address review feedback* sync `trap.h` with `trap_encoding.rs`...and add const assertions to `trap.rs` to help avoid future divergence. List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat

a80dd80d - Cranelift: Rewrite conditional branches to unconditional traps into conditional traps during legalization (#10988)

Mon, 09 Jun 2025 20:17:02 +0000

Cranelift: Rewrite conditional branches to unconditional traps into conditional traps during legalization (#10988)* Cranelift: Legalize via a backwards walk, rather than forwardsNote: the test expectation change in `filetests/egraph/misc.clif` is simplybecause we happen to change the order in which we created the legalized`stack_addr` instructions that get GVN'd together, and therefore also changedtheir relative value numbering. We dedupe to the value that occurs first in thefunction, which is the one inserted into the DFG *after* the other now becauseof the backwards traversal, and it therefore has a different value number frombefore. The resulting program is identical, modulo value numbering.* Cranelift: Rewrite conditional branches to unconditional traps into conditional traps during legalizationGiven this instruction:```clifbrif v0, block1, block2```If we know that `block1` does nothing but immediately trap then we can rewritethat `brif` into the following:```cliftrapz v0, jump block2```(And we can do the equivalent with `trapz` if `block2` immediately traps).This transformation allows for the conditional trap instructions to be GVN'd andfor our egraphs mid-end to generally better optimize the program. Weadditionally have better codegen in our backends for `trapz` than branches tounconditional traps.Fixes https://github.com/bytecodealliance/wasmtime/issues/10941* Update CLIF filetests and Wasmtime disas tests List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat

701af54f - Cranelift: egraphs: fix a few sources of exponential rewrite blowup. (#10579)

Tue, 15 Apr 2025 16:30:45 +0000

Cranelift: egraphs: fix a few sources of exponential rewrite blowup. (#10579)This arrived as a fuzzbug [1] with some very interesting optimizationbehavior. The test case has sequences of `(select _ x x)` operators --that is, conditional selects with both inputs the same -- that arechained together sequentially. A few aspects of the egraph framework andour optimization rules conspired to create exponential blowup:- We have a rewrite rule for `(select _ x x) -> x`, but we do not subsume; this means that we create an eclass for both. This in itself is not a problem; however...- We have some *other* rules that look through the inputs to the select to detect other cases (e.g.: select between constants 1 and 0, or 0 and 0, or ...), so we traverse both inputs;- And we also do nested rewrites, so when the rewrite rule for `(select _ x x) -> x` fires, and the `x` is itself another select in a long chain of selects, we traverse all possible paths (through first or second args) to the roots. In effect we get an eclass that has the ultimate root and then 2^n combinations of `select` nodes on top of that.This got worse with the recent change to canonicalize less (forsimpler/cheaper compilation), hence the fuzzbug timeouts.This PR includes a few fixes, all complementary to each other:- The `(select _ x x) -> x` rule now subsumes; this is another case where we have a strictly better rewrite and so we should short-circuit the eclass blowup.- The rewrite runner sorts and dedups returned value numbers; in debugging the above I noticed we were getting two rules producing the same rewritten value and we were adding the same value twice with two union nodes.- The rewriter keeps a total eclass size per root and limits the total eclass size to a fixed limit (currently 5). We thus now have limits in three different axes: depth of eager rewrites (5); number of returned matches (also 5); and total size of eclass (5). The first two don't necessarily imply the third because we otherwise can keep unioning on top of an eclass and (as seen above) see exponential blowup.[1]: https://oss-fuzz.com/testcase-detail/4806924172591104 List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat

c22b3cb9 - Reuse Wasm linear memories code for GC heaps (#10503)

Fri, 11 Apr 2025 21:15:55 +0000

Reuse Wasm linear memories code for GC heaps (#10503)* Reuse code for Wasm linear memories for GC heapsInstead of bespoke code paths and structures for Wasm GC, this commit makes itso that we now reuse VM structures like `VMMemoryDefinition` and bounds-checkinglogic. Notably, we also reuse all the associated bounds-checking optimizationsand, when possible, virtual-memory techniques to completely elide them.Furthermore, this commit adds support for growing GC heaps, reusing themachinery for growing memories, and makes it so that GC heaps always start outempty. This allows us to properly delay allocating the GC heap's storage until aGC object is actually allocated.Fixes #9350* fix c api compilation* use assert_contains* remove no-longer-necessary extra memory config from limiter tests* Helper for retry-after-maybe-async-gc in libcalls* Clean up some comments* fix wasmtime-fuzzing and no-gc compilation* fix examples* fix no-gc+compiler build* fix build without pooling allocator* fix +cranelift +gc-drc -gc-null builds* fix table hash key stability test* fix oracle usage of `ExternRef::new`* fix +gc -gc-null -gc-drc build* fix wasmtime-fuzzing* make `StorePtr` wrap a `NonNull`* Fix some doc tests* Remove some unnecessary retry helpers now that `FooRef::new` will auto-gc* fix things after rebase* Reorganize collection/growth methods for GC heap* rename BoundsCheck variants* fix cfg'ing of gc only code* Fix doc tests* fix one more gc cfg* disable GC heap OOM test on non-64-bit targets List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat

7bf31723 - Cranelift: simplify some side-effectful instructions in ISLE (#10524)

Tue, 08 Apr 2025 17:57:03 +0000

Cranelift: simplify some side-effectful instructions in ISLE (#10524)* Cranelift: simplify some side-effectful instructions in ISLEThis commit adds a new top-level ISLE entrypoint specifically for instructionsin the side-effectful skeleton: `simplify_skeleton`. While these rewrites areprocessed during the egraph pass, values from skeleton instructions still do notget inserted into the egraph. Indeed, `simplify_skeleton` operateson *instructions* rather than *values* because we do not represent side effectsas values; values do not have side effects in CLIF, instructions do. Therefore,rather than doing a whole dynamic-programming style extraction of the bestcandidate simplification like we do with the egraph, we take an eager and greedyapproach.Furthermore, `simplify_skeleton` is limited only to skeleton instructions thatdo not involve control-flow or terminators right now. This is because changingthe control-flow graph can change whether a use is dominated by a def or not,and we do not currently have the machinery to track and fix up invalidateduses. Addressing this is left for future commits.* fix `MIN / -1` cprop and add negative tests for things simplify_skeleton cannot handle yet List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat

4d876371 - Add "pure" flag to `ir::MemFlags` (#10340)

Thu, 06 Mar 2025 21:51:49 +0000

Add "pure" flag to `ir::MemFlags` (#10340)* Add "pure" flag to `ir::MemFlags`This flag represents whether the memory operation's safety (e.g. the validity ofits `notrap` and `readonly` claims) is purely a function of its datadependencies.If this flag is `true`, then it is okay to code motion this instruction toarbitrary locations, in the function, including across blocks and conditionalbranches, so long as data dependencies (and trap ordering, if relevant) areupheld.If this flag is `false`, then the memory operation's safety potentially reliesupon invariants that are not reflected in its data dependencies, and thereforeit is not safe to code motion this operation. For example, this operation couldbe in a block that is dominated by a control-flow bounds check that makes thisoperation safe, and that invariant is not reflected in its operands. It would beunsafe to code motion such an instruction above its associated bounds check,even if its data dependencies would still be satisfied.I've added this flag because we were doing exactly that kind of code motionwhere we moved a `readonly` and `notrap` memory operation past its associatednull-check and therefore it was no longer safe to perform and we would get asegfault. This could only be triggered when the Wasm typed-function-referencesproposal was enabled, which is not a tier-1 proposal, so it is not considered avulnerability. Nonetheless, it is a pretty scary kind of bug, and other codepaths weren't affected due to pretty subtle interactions. And this is themotivation for the new "pure" flag: without needing to explicitly opt intodata-dependency-based code motion (i.e. set the "pure" flag), it is too easy toaccidentally move loads past their control-flow-based safety guards.* fix load-hoisting test; also test that non-pure loads don't hoist* Rename `pure` flag to `can_move` List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat

a88eb702 - Cranelift: dedupe `trap[n]z` instructions (#10004)

Tue, 14 Jan 2025 18:28:51 +0000

Cranelift: dedupe `trap[n]z` instructions (#10004)* Cranelift: dedupe `trap[n]z` instructionsThis commit extends our existing support for merging idempotently side-effectfulinstructions that produce exactly one value to those that produce zero or onevalue, and marks the `trap[n]z` instructions as having idempotent sideeffects. This cleans up a lot test cases in our `disas` test suite, particularlythose related to explicit bounds checks and GC.As an aside, it seems like it should be easy to extend this to idempotentlyside-effectful instructions that produce multiple values as well, but I don'tbelieve we have any such instructions, so I didn't bother.* Update more disas tests* review feedback List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat

10138516 - Shuffle fields in `VMRuntimeLimits` (#9739)

Thu, 05 Dec 2024 17:39:47 +0000

Shuffle fields in `VMRuntimeLimits` (#9739)* Shuffle fields in `VMRuntimeLimits`Right now this structure has a pointer-sized field, two 64-bit integers,and then three pointer-sized fields. This structure's layout isnontrivial to calculate on 32-bit platforms as it needs to take thealignment of 64-bit integers into account which differs between ARM andx86 for example. To make this easier shuffle all the 64-bit integers are nowfirst, which means we don't have to worry about alignment.I'll note that this particular ordering is still a bit brittle becausewe might need to shuffle things again if more fields are added. Thatbeing said any misalignment is caught during testing of the `wasmtime`crate so there's not much danger in adding more things, it'll justrequire updating a few more locations.* Update test expectations List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat

83bf774d - Add the "null" garbage collector (#9484)

Thu, 31 Oct 2024 17:46:17 +0000

Add the "null" garbage collector (#9484)* Add the "null" garbage collectorThe null collector does not actually collect any garbage, it simplybump-allocates until the heap is exhausted, at which point further allocationattempts will fail. It does not require any GC barriers.Users can configure which collector to use via the `wasmtime::Config::collector`method or the `-C collector=drc|null` CLI flag. The `wasmtime::Collector` enumeration,similar to the `wasmtime::Strategy` enumeration but for choosing a collectorrather than a compiler, additionally has a table summarizing the properties andcharacteristics of our current set of collector implementations.Finally, we also run `.wast` tests that exercise GC types under both the DRC andnull collectors. I tried to avoid running tests that are not related to GC underboth configurations just to avoid a combinatorial blow up.* cargo fmt* fix +gc -gc-null -gc-drc build* Fix some warnings in various cargo feature combo builds* Fix some more warnings in certain build configs* Fix unit tests for null GC* Fill in some placeholder comments that I forgot to write* Fix issues where we ask for a GC store when we don't actually need oneWhich was causing test failures, since we no longer return a GC store with adummy heap.* Add fuzzing config support for different collectors* address review feedback* fix cmake tests* Fix test compilation after rebase* Fix GC tests under MIRI List of files: /wasmtime-44.0.1/tests/disas/gc/null/multiple-array-get.wat