Changes in context.rs

2f7dbd61 - PCC: remove proof-carrying code (for now?). (#12800)

Tue, 31 Mar 2026 04:36:33 +0000

PCC: remove proof-carrying code (for now?). (#12800)In late 2023, we built out an experimental feature calledProof-Carrying Code (PCC), where we attached "facts" to values in theCLIF IR and built verification of these facts after lowering tomachine instructions. We also added "memory types" describing layoutof memory and a "checked" flag on memory operations such that we couldverify that any checked memory operation accessed valid memory (asdefined by memory types attached to pointer values viafacts). Wasmtime's Cranelift backend then put appropriate memory typesand facts in its IR such that all accesses to memory (aspirationally)could be checked, taking the whole mid-end and lowering backend ofCranelift out of the trusted core that enforces SFI.This basically worked, at the time, for static memories; but never fordynamic memories, and then work on the feature lostprioritization (aka I had to work on other things) and I wasn't ableto complete it and put it in fuzzing/enable it as a production option.Unfortunately since then it has bit-rotted significantly -- as we addnew backend optimizations and instruction lowerings we haven't keptthe PCC framework up to date.Inspired by the discussion in #12497 I think it's time to deleteit (hopefully just "for now"?) unless/until we can build it again. Andwhen we do that, we should probably get it to the point of validatingrobust operation on all combinations of memory configurations beforemerging. (That implies a big experiment branch rather than a bunch ofeager PRs in-tree, but so it goes.) I still believe it is possible tobuild this (and I have ideas on how to do it!) but not right now. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

3a14fa39 - refactor(cranelift): merge DominatorTreePreorder into DominatorTree (#11596)

Wed, 03 Sep 2025 18:56:07 +0000

refactor(cranelift): merge DominatorTreePreorder into DominatorTree (#11596)* refactor(cranelift): merge DominatorTreePreorder into DominatorTreeIntegrate preorder functionality directly into DominatorTree toeliminate duplicate computation and improve performance.This eliminates the need for a separate DominatorTreePreorder datastructure, reducing memory usage and providing O(1) block dominancechecks by default. Block dominance checks throughout the compiler nowbenefit from constant-time performance instead of O(depth) treetraversal.* refactor(cranelift): implement the new unified DominatorTreeRemove separate DominatorTreePreorder computation and use unified API:- Context: Remove domtree_preorder field, simplify compute_domtree()- AliasAnalysis: Switch from DominatorTreePreorder to DominatorTree- Update dominance checks to use general dominates() methodAll dominance checks in alias analysis now automatically benefit fromO(1) block dominance performance when instructions are in differentblocks.* refactor(cranelift): update optimization passes for DominatorTree* refactor(cranelift): update verifier and tests for new DominatorTreeSSA dominance validation in the verifier now benefits from O(1)block-to-block dominance checks, improving compilation performanceduring debug builds with verification enabled. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

968952ab - Cranelift: introduce a function inliner (#11210)

Thu, 10 Jul 2025 18:32:30 +0000

Cranelift: introduce a function inliner (#11210)* Cranelift: introduce a function inlinerThis comit adds "inlining as a library" to Cranelift; it does _not_ provide acomplete, off-the-shelf inlining solution. Cranelift's compilation context isper-function and does not encompass the full call graph. It does not know whichfunctions are hot and which are cold, which have been marked the equivalent of`#[inline(always)]` versus `#[inline(never)]`, etc... Only the Cranelift usercan understand these aspects of the full compilation pipeline, and these thingscan be very different between (say) Wasmtime and `cg_clif`. Therefore, thisinfrastructure does not attempt to define hueristics for when inlining aparticular call is likely beneficial. This module only provides hooks for theCranelift user to tell Cranelift whether a given call should be inlined or not,and the mechanics to inline a callee into a particular call site when the userdirects Cranelift to do so.This commit also creates a new kind of filetest that will always inline calls tofunctions that have already been defined in the file. This lets us exercise theinliner in filetests.Fixes https://github.com/bytecodealliance/wasmtime/issues/4127* Address review feedback* Require callee bodies are pre-legalized List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

e33e0f21 - feat(cranelift): Use DominatorTreePreorder in more places (#11098)

Tue, 24 Jun 2025 15:20:50 +0000

feat(cranelift): Use DominatorTreePreorder in more places (#11098) List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

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/cranelift/codegen/src/context.rs

8a42768f - Update nightly used in CI (#10957)

Fri, 06 Jun 2025 18:06:28 +0000

Update nightly used in CI (#10957)A new lint was added to rustc so this updates the nightly used in CI andthen additionally fixes the lints that are firing. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

3da7fc8e - [DI] Dump value label assignments in a table (#10549)

Tue, 08 Apr 2025 19:42:14 +0000

[DI] Dump value label assignments in a table (#10549)* Dump compilation start/end* [DI] Log value label ranges in a tableSample table:|Inst |IP |VL0 |VL1 |VL3 |VL4 |VL5 |VL7 |VL10 |VL11 |VL4294967294||--------|----|--------|---------|---------|--------|--------|--------|---------|--------|------------||Inst 0 |53 | | | | | | | | | | | | | | | | | | ||Inst 1 |53 | | | | | | | | | | | | | | | | | | ||Inst 2 |60 |v194|p2i|v232|p12i| | | | | | | | | | | | |v192|p7i ||Inst 3 |64 |* |p2i|* |p12i|v231|p13i| | | | | | | | | | |* |p7i ||Inst 4 |68 |* |p2i|* |p12i|* |p13i| | | | | | | | | | |* |p7i ||Inst 5 |72 |* |p2i|* |p12i|* |p13i| | | | | | | | | | |* |p7i ||Inst 6 |76 |* |p2i|* |p12i|* |p13i| | | | | | | | | | |* |p7i ||Inst 7 |87 |* | |* |p12i|* |p13i| | | | | | | | | | |* |p7i ||Inst 8 |92 |* | |* |p12i|* |p13i|v227|p0i| | | | | | | | |* |p15i ||Inst 9 |94 |* | |v204| |v204| |v204| |v204| |v204| |v204| |v204| |* |p15i ||Inst 10 |100 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 11 |105 |* | |* | |* | |* | |v226|p9i|* | |* | |* | |* |p15i ||Inst 12 |109 |* | |* | |* | |* | |* | |v225|p9i|* | |* | |* |p15i ||Inst 13 |114 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 14 |119 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 15 |125 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 16 |129 |* | |* | |* | |* | |* | |* | |v223|p11i|* | |* |p15i ||Inst 17 |134 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 18 |134 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 19 |139 |* | |* | |* | |* | |* | |* | |* | |v222|p0i|* |p15i ||Inst 20 |143 |* | |* | |* | |* | |* | |* | |* | |* |p0i|* |p15i ||Inst 21 |143 |* | |* | |* | |* | |* | |* | |* | |* |p0i|* | |This will make it much easier to diagnose problems with incomplete/missing live ranges. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

82c0a09b - Simplify aegraphs by removing union-find and canonical eclass IDs. (#10471)

Wed, 26 Mar 2025 17:18:18 +0000

Simplify aegraphs by removing union-find and canonical eclass IDs. (#10471)I was recently re-thinking through some of the core data structuredesign in our aegraph implementation, and wondered: do we really needthe union-find data structure, the notion of "canonical" ID for aneclass separate from its latest ID (root of union-node tree), and thehashcons-key canonicalization using all of this? It's an awful lot ofcomplexity and has led to some fairly subtle bugs (e.g., #6126), and isgenerally unsatisfying.I had the realization: the only case where the distinction betweencanonical and latest ID matters is when we expand an eclass after itsinitial (eager) rewriting, which happens before we see its uses. If wehypothesize that this happens rarely, then it should be fine tocanonicalize based only on latest ID -- we shouldn't lose much (and wecan measure this loss empirically).The chief case where this kind of "late eclass expansion" still happensis: if we have some expression E1 that eventually rewrites to E2 viasome simplification, and E2 already exists earlier in the program, thenE1 will join the eclass. If we then have some `E3 := E1 + 1`, and later`E4 := E2 + 1`, we need the union-find canonicalization for E4 to GVN toE3. Otherwise, the latest ID for the eclass that eventually contains E1and E2 is different at the time that E3 uses it (and is GVN'd andrewritten) and when E4 does. Put another way: E3 captures a snapshot ofits operand's eclass before a new node joins it, and is neverreprocessed when that happens, so E3 remains distinct.But if the `E2 -> E1` rewrite is truly "directional" toward a betterrepresentation that we will always want to choose -- say, `x + 0 -> x`,or any constant-propagation in general -- then if the eager rewritingfor E2 produces E1's eclass ID directly *without* adding E2 to itsnodes, then all users will still canonicalize as before. This "onlyreturn the rewrite target, don't union with it" before is exactly our`subsume` operator.Put another way: subsumption prevents growing eclasses later, sosnapshots in time remain the latest, and everyone canonicalizes with thesame ID. We move to a true immutable data structure, with simplehashconsing with no magic.The rewrite semantics are then much simpler too: if any value ismarked "subsume", we pick it (pick an arbitrary one if multiple) as ourrewrite result; otherwise, create an eclass with the original rewriteinput and all rewrite outputs (by creating union-nodes in the DFG). Noauto-subsume or factoring in availability -- that's it. "Subsume" means:always pick the rewritten value, don't keep the original, and we use itwhenever that's unambiguously true for better canonicalization.Given that, it turns out that we can remove the union-find mechanismentirely. It also turns out that we can unify the scoped-hashmap for"effectful/idempotent ops" with the ordinary hashmap for pure ops;everything can be scoped. To get working LICM we do need to retain our"available block" mechanism, but only to insert values at a higher scopelevel in the scoped hashmap -- it is now heuristic, not load-bearing forcorrectness.I suspect that the fixpoint loop computing analysis results can go awaytoo, now that we truly don't update arguments -- we have a simpleimmutable data structure with everything snapshotted at creation -- butI haven't made that change yet.This change appears to be "in the noise" in both runtime and compiletime -- a Sightglass run on the default suite shows only```compilation :: cycles :: benchmarks/pulldown-cmark/benchmark.wasm Δ = 551234.50 ± 514580.62 (confidence = 99%) new.so is 1.00x to 1.01x faster than old.so! [61669181 72513567.85 98139932] new.so [60991071 73064802.35 120044089] old.soexecution :: cycles :: benchmarks/bz2/benchmark.wasm Δ = 232827.80 ± 204621.12 (confidence = 99%) old.so is 1.00x to 1.01x faster than new.so! [67208140 72812782.32 89996076] new.so [69531172 72579954.52 80530142] old.so```which seem like suitably small swings that are fine. Spot-checking theaegraph stats on the same function before-and-after shows the sameoptimizations happening in all functions I examined, and we see thecompile-tests showing no movement except for a value renumbering in onecase. So: no effect objectively, but deletes code and significantlysimplifies the core algorithm. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

eb0428eb - Lower conditional traps in backend (#9072)

Mon, 23 Sep 2024 14:59:36 +0000

Lower conditional traps in backend (#9072)* Lower conditional traps in backendInstead of legalizing `trapz` and `trapnz` in the mid-end, we now take them allthe way to the backend. This allows us to GVN them and remove redundant trapchecks. This also allows us to avoid creating new blocks in the legalizer andotherwise invalidating the control-flow graph.* Lower `trap[n]z` clif instructions in Pulley* Update disas tests---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

f96aac79 - Deprecate Context::compile_and_emit (#9281)

Thu, 19 Sep 2024 15:18:01 +0000

Deprecate Context::compile_and_emit (#9281)The only thing it does over Context::compile is writing the machine codeto a Vec specified by the user. Every user of Context::compile_and_emitin Cranelift didn't actually need ownership over the machine code bytesand thus would have been able to use Context::compile instead to avoidan unnecessary allocation. This commit moves all in-tree users ofcompile_and_emit to compile and additionally to avoid other users addingan unnecessary allocation as they though it to be necessary, this commitadditionally deprecates compile_and_emit. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

b3636ff6 - Introduce the `cranelift-bitset` crate; use it for stack maps in both Cranelift and Wasmtime (#8826)

Tue, 18 Jun 2024 15:44:38 +0000

Introduce the `cranelift-bitset` crate; use it for stack maps in both Cranelift and Wasmtime (#8826)* Introduce the `cranelift-bitset` crateThe eventual goal is to deduplicate bitset types between Cranelift and Wasmtime,especially their use in stack maps.* Use the `cranelift-bitset` crate inside both Cranelift and WasmtimeMostly for stack maps, also for a variety of other random things where`cranelift_codegen::bitset::BitSet` was previously used.* Fix stack maps unit test in cranelift-codegen* Uncomment `no_std` declaration* Fix `CompountBitSet::reserve` method* Fix `CompoundBitSet::insert` method* Keep track of the max in a `CompoundBitSet`Makes a bunch of other stuff easier, and will be needed for replacing`cranelift_entity::EntitySet`'s bitset with this thing anyways.* Add missing parens* Fix a bug around insert and reserve* Implement `with_capacity` in terms of `new` and `reserve`* Rename `reserve` to `ensure_capacity` List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

c477424f - cranelift: Resolve CLIF aliases before lowering (#8606)

Wed, 15 May 2024 00:20:37 +0000

cranelift: Resolve CLIF aliases before lowering (#8606)The egraph pass was already doing this, when it ran, and it never addsany aliases. So do it slightly earlier and unconditionally, and avoidneeding to resolve any aliases during lowering. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

b869b66b - cranelift: Delete redundant DCE optimization pass (#8227)

Mon, 13 May 2024 16:12:48 +0000

cranelift: Delete redundant DCE optimization pass (#8227)The egraph pass and the dead-code elimination pass both removeinstructions whose results are unused. If the optimization level is"none", neither pass runs, and if it's anything else both passes run. Idon't think we should do this work twice.Note that the DCE pass is different than the "eliminate unreachablecode" pass, which removes entire blocks that are unreachable from theentry block. That pass might still be necessary. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

72a3b8b9 - NaN-canonicalization without branching on x64 (#8313)

Tue, 09 Apr 2024 11:08:04 +0000

NaN-canonicalization without branching on x64 (#8313)* NaN-canonicalization without branching on x64Modify the cranelift pass that performs NaN-canonicalization to avoidbranches on x64. The current implementation uses two branches.* remove old fcmp case* Revert "remove old fcmp case"This reverts commit 48c3712b7ecfc75f5183b688677391f99e9fe8fe.* add filetests* use old version for riscv List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

d7c96a9e - PCC: add facts to all relevant iconsts to handle propagation through opts. (#8173)

Tue, 19 Mar 2024 00:43:54 +0000

PCC: add facts to all relevant iconsts to handle propagation through opts. (#8173)We have various constant-propagation/folding rules in the mid-end thatgenerate new `iconst`s in place of other expressions. We got a fuzzbugwith PCC wherein it was not able to verify that an iadd-iadd-uextendcombination generating a Wasm address was in-range when rulesreassociated the iadds to put constants together. Rather than carefullyaugment all rules to propagate constant facts only where they exist onthe inputs, I opted to add a hook to the optimizer to generate brand-newassertions on *all* iconsts that we insert. This adds a little more workduring verification (not too much hopefully: it's pretty low-overhead tocheck that `mov $1, %rax` puts `1` in `rax`) but should provide broadercoverage of interesting corner-cases where optimization breaks the PCCchain.Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=67432. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

caa555f8 - cranelift: Enable "chaos mode" in egraph pass (#7968)

Tue, 20 Feb 2024 22:26:21 +0000

cranelift: Enable "chaos mode" in egraph pass (#7968)First of all, thread a "chaos mode" control-plane into Context::optimizeand from there into EgraphPass, OptimizeCtx, and Elaborator.In this commit we use the control-plane to change the followingbehaviors in ways which shouldn't cause incorrect results:- Dominator-tree block traversal order for both the rule application and elaboration passes- Order of evaluating optimization alternatives from `simplify`- Choose worst values instead of best in each eclassCo-authored-by: L. Pereira List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

e7ab3a46 - unionfind: robustly avoid changing `Idx`s in the GVN map (#7746)

Mon, 12 Feb 2024 16:20:55 +0000

unionfind: robustly avoid changing `Idx`s in the GVN map (#7746)* unionfind: robustly avoid changing `Idx`s in the GVN mapStop hoping that keeping the smallest Idx as canonical will yield goodresults, and instead explicitly inform the UnionFind of what we expectnot to move.Fixes #6126* unionfind: track unions of pinned indices as statsEmitting a warning in this situation is too much. List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

f466aa26 - Skeleton and initial support for proof-carrying code. (#7165)

Fri, 06 Oct 2023 22:31:23 +0000

Skeleton and initial support for proof-carrying code. (#7165)* WIP veriwasm 2.0Co-Authored-By: Chris Fallin * PCC: successfully parse some simple facts.Co-authored-by: Nick Fitzgerald * PCC: plumb facts through VCode and add framework on LowerBackend to check them.Co-authored-by: Nick Fitzgerald * PCC: code is carrying some proofs! Very simple test-case.Co-authored-by: Nick Fitzgerald * PCC: add a `safe` flag for checked memory accesses.* PCC: add pretty-printing of facts to CLIF output.* PCC: misc. cleanups.* PCC: lots of cleanup.* Post-rebase fixups and some misc. fixes.* Add serde traits to facts.* PCC: add succeed and fail tests.* Review feedback: rename `safe` memflag to `checked`.* Review feedback.---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs

b9134e21 - Call verifier after egraph pass (#6858)

Fri, 18 Aug 2023 09:16:52 +0000

Call verifier after egraph pass (#6858) List of files: /wasmtime-44.0.1/cranelift/codegen/src/context.rs