History log of /wasmtime-44.0.1/tests/disas/dead-code.wat (Results 1 – 7 of 7)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6
# 7e0331c2 11-Feb-2026 Chris Fallin <[email protected]>

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 #1

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 ability
to keep a handle to a stack frame as long as execution is frozen, and
keep multiple of these handles around, alongside the `Store`, without
any handle directly holding a borrow of the store.

The frame handles work by means of an "execution version" scheme: the
idea is that whenever any execution resumes in a given store, all
handles to existing frames could be invalidated, but if no such
execution occurs, all handles should still be valid. A tuple of
(globally unique for process lifetime) store ID, and execution version
within that store, should be sufficient to uniquely identify any
frozen-stack period during execution. This accomplishes cheap handle
invalidation without the need to track existing handles.

This PR also implements a cache of parsed frame-table data. Previously
this was lazily parsed by the cursor as it walked up a stack, but with
multiple handles hanging around, and with handles meant to be cheap to
hold and clone, and with handles being invalidated eagerly, it makes
much more sense to persist this parsed metadata at the `Store` level.
(It cannot persist at the `Engine` level because PCs are local per
store.)

* 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).

show more ...


Revision tags: v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0, v32.0.0, v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0, v28.0.1, v28.0.0
# 10138516 05-Dec-2024 Alex Crichton <[email protected]>

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

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 is
nontrivial to calculate on 32-bit platforms as it needs to take the
alignment of 64-bit integers into account which differs between ARM and
x86 for example. To make this easier shuffle all the 64-bit integers are now
first, which means we don't have to worry about alignment.

I'll note that this particular ordering is still a bit brittle because
we might need to shuffle things again if more fields are added. That
being said any misalignment is caught during testing of the `wasmtime`
crate so there's not much danger in adding more things, it'll just
require updating a few more locations.

* Update test expectations

show more ...


Revision tags: v27.0.0, v26.0.1, v25.0.3, v24.0.2, v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1, v25.0.1, v25.0.0, v24.0.0, v23.0.2, v23.0.1, v23.0.0, v22.0.0
# 4896b663 22-May-2024 Alex Crichton <[email protected]>

Fix tail calls being turned on by default (#8682)

* Fix tail calls being turned on by default

Logic in `Config` to conditionally enable tail calls wasn't handling the
case where the configured comp

Fix tail calls being turned on by default (#8682)

* Fix tail calls being turned on by default

Logic in `Config` to conditionally enable tail calls wasn't handling the
case where the configured compiler strategy was `Strategy::Auto` meaning
that by default tail calls weren't actually enabled. This commit
refactors handling of `Strategy` to avoid storing `Strategy::Auto` in
`CompilerConfig` so tests against it can use either cranelift or winch.

* Update disas tests

* Update Winch tests to using winch

show more ...


Revision tags: v21.0.1, v21.0.0, v20.0.2, v20.0.1, v20.0.0, v17.0.3, v19.0.2, v18.0.4, v19.0.1
# 138148a5 26-Mar-2024 Jamey Sharp <[email protected]>

Resolve value aliases in disas tests (#8239)

This reverts commit 6c5184809db3a92de4ee0c718c403bedc9a9ff4f,
"Cranelift: resolve value aliases when printing CLIF functions (#8214)",
then applies the s

Resolve value aliases in disas tests (#8239)

This reverts commit 6c5184809db3a92de4ee0c718c403bedc9a9ff4f,
"Cranelift: resolve value aliases when printing CLIF functions (#8214)",
then applies the same effect a different way.

In discussion on #8223, we decided to handle this a different way. So
I've introduced a method on DataFlowGraph which eliminates all value
aliases, and we can call it when necessary. If that function is not
called then the CLIF printer should print value aliases the same way it
did before #8214.

In this PR, I've specifically called it in disas tests. The changes to
write.rs and frontend.rs are from the revert, while the changes to
disas.rs are new.

In these tests, value aliases are just clutter that distracts from
understanding what code will actually be generated. They may change due
to changes in legalization, but that doesn't signal anything about
whatever the test was intended to check.

Because the new helper deletes aliases after it's done resolving them,
those aliases now disappear from the test expectations. Aside from that,
the test expectations are unchanged compared to what #8214 did.

show more ...


# 6c518480 22-Mar-2024 Nick Fitzgerald <[email protected]>

Cranelift: resolve value aliases when printing CLIF functions (#8214)

This makes the CLIF much easier to follow.


# ead7f735 21-Mar-2024 Alex Crichton <[email protected]>

Compile out wmemcheck-related libcalls when not enabled (#8203)

Currently even when the `wmemcheck` Cargo feature is disabled the
various related libcalls are still compiled into `wasmtime-runtime`.

Compile out wmemcheck-related libcalls when not enabled (#8203)

Currently even when the `wmemcheck` Cargo feature is disabled the
various related libcalls are still compiled into `wasmtime-runtime`.
Additionally their signatures are translated when lowering functions,
although the signatures are never used. This commit adds `#[cfg]`
annotations to compile these all out when they're not enabled.

Applying this change, however, uncovered a subtle bug in our libcalls.
Libcalls are numbered in-order as-listed in the macro ignoring `#[cfg]`,
but they're assigned a runtime slot in a `VMBuiltinFunctionsArray`
structure which does respect `#[cfg]`. This meant, for example, that if
`gc` was enabled and `wmemcheck` was disabled, as is the default for our
tests, then there was a hole in the numbering where libcall numbers were
mismatched at runtime and compile time.

To fix this I've first added a const assertion that the runtime-number
of libcalls equals the build-time number of libcalls. I then updated the
macro a bit to plumb the `#[cfg]` differently and now libcalls are
unconditionally defined regardless of cfgs but the implementation is
`std::process::abort()` if it's compiled out.

This ended up having a large-ish impact on the `disas` test suite. Lots
of functions have fewer signatures translation because wmemcheck, even
when disabled, was translating a few signatures. This also had some
assembly changes, too, because I believe functions are considered leaves
based on whether they declare a signature or not, so declaring an unused
signature was preventing all wasm functions from being considered leaves.

show more ...


Revision tags: v19.0.0
# 27153d07 15-Mar-2024 Alex Crichton <[email protected]>

Move all tests out of `cranelift-wasm` (#8147)

* Move remaining `*.wat` tests out of cranelift-wasm/wasmtests

Move these up to Wasmtime's misc testsuite to get translated and
instantiated by Wasmti

Move all tests out of `cranelift-wasm` (#8147)

* Move remaining `*.wat` tests out of cranelift-wasm/wasmtests

Move these up to Wasmtime's misc testsuite to get translated and
instantiated by Wasmtime.

Note that the max-function-index-in-name-section test was removed here
as that's tested by the support added in #3509.

* Remove cranelift-wasm test for name section

This is pretty thoroughly tested elsewhere in Wasmtime that we respect
the name section, for example many of the trap tests assert that the
name of the function comes from the text format.

* Move reachability tests out of cranelift-wasm

Instead add them to the disassembly test suite to ensure we don't
generate dead code. Additionally this has a lot of coverage via fuzzing
too.

* Move more tests out of cranelift-wasm

Move them into `tests/disas` so we can easily see the CLIF.

show more ...