Changes in dfg.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/ir/dfg.rs

ba8f7d70 - Cranelift: update ValueDataPacked to support full Value range. (#12613)

Wed, 18 Feb 2026 15:52:45 +0000

Cranelift: update ValueDataPacked to support full Value range. (#12613)This updates the `ValueDataPacked` scheme from the old``` (enum tag) (CLIF type) (value 1) (value 2)/// | tag:2 | type:14 | x:24 | y:24```encoding in a `u64` to a new```/// | tag:2 | type:14 | x:32 | y:32```encoding, with a `packed` tag attribute to ensure the struct fits in10 bytes. This permits the full range of `Value` (a `u32` entityindex) to be encoded, removing the remaining major limit on functionbody size after the work in #12611 to address #12229.Curiously, this appears to be a *speedup* in compile time of 3-5% onbz2 and 3% on spidermonkey-json (Sightglass, 50 data points each). Mybest guess as to why is that putting the value fields in their own`u32`s allows for quick access without shifts/masks, which is actuallybetter than the unaligned accesses (caused by 10-byte size) -- whichhave no penalty on modern mainstream CPUs -- and 25% size inflation ofthe value-definitions array. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

3ecb338e - Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)

Tue, 29 Jul 2025 14:32:54 +0000

Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)* Wasmtime: Add (optional) bottom-up function inlining to Wasm compilationThis commit plumbs together two pieces of recently-added infrastructure:1. function inlining in Cranelift, and2. the parallel bottom-up inlining scheduler in Wasmtime.Sprinkle some very simple inlining heuristics on top, and this gives us functioninlining in Wasm compilation.The default Wasmtime configuration does not enable inlining, and when we doenable it, we only enable it for cross-component calls by default (sincepresumably the toolchain that produced a particular core Wasm module, like LLVM,already performed any inlining that was beneficial within that module, but thattoolchain couldn't know how that Wasm module would be getting linked togetherwith other modules via component composition, and so it could not have done anycross-component inlining). For what it is worth, there is a config knob toenable intra-module function inlining, but this is primarily for use by ourfuzzers, so that they can easily excercise and explore this new inliningfunctionality.All this plumbing required some changes to the `wasmtime_environ::Compiler`trait, since Winch cannot do inlining but Cranelift can. This is mostlyencapsulated in the new `wasmtime_environ::InliningCompiler` trait, for the mostpart. Additionally, we take care not to construct the call graph, or any otherdata structures required only by the inliner and not regular compilation, bothwhen using Winch and when using Cranelift with inlining disabled.Finally, we add a `disas` test to verify that we successfully inline a series ofcalls from a function in one component, to a cross-component adapter function,to a function in another component. Most test coverage is expected to come fromour fuzzing, however.* Fix dead code warning when not `cfg(feature = "component-model")`* fix winch trampoline compilation* Move CLI options to codegen* Move parameters into struct* Use an index set for call-graph construction* Smuggle inlining heuristic options through cranelift flags* Remove old CLI flags* set tunables before settings* Only configure inlining options for cranelift in fuzzing List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

4590076f - Cranelift: support dynamic contexts in exception-handler lists. (#11321)

Sat, 26 Jul 2025 01:35:57 +0000

Cranelift: support dynamic contexts in exception-handler lists. (#11321)In #11285, we realized that Wasm semantics require us to match ondynamic instances of exception tags, rather than static tag types. Thisfundamentally requires the unwinder to be able to resolve the currentWasm instance for each Wasm frame on the stack that has any handlers,and our frame format does not provide this today.We discussed many options, some of which solve the more general problem(Wasm vmctx for any frame), but ultimately landed on a notion of"dynamic context for evaluating tags", specific to Cranelift'sexception-catch metadata; and storing that context and carrying itthrough to a place that is named in the unwind metadata. The reasoningis fairly straightforward: we cannot afford a more general approach thatstores vmctx in every frame (I measured this at 20% overhead for arecursive-Fibonacci benchmark that is call-intensive); and inliningmeans that we may have *multiple* contexts at any given program point,each associated with a different slice of the handler tags; so we need amechanism that, *just for a try-call*, intersperses contexts with tags(or puts a context on each tag) and stores these somewhere that theexception-unwind ABI doesn't clobber (e.g., on the stack).This PR implements "option 4" from that issue, namely, *dynamicexception contexts*. The idea is that this is the dual to exceptionpayload: while payload lets the unwinder communicate state *to* thecatching code, context lets the unwinder take state *from* the catchingcode that lets it decide whether the tag is a match. Because ofinlining, we need to either associate (optional) context with every tag,or intersperse context-updates with handler tags. I've opted for thelatter for efficiency at the CLIF level (in most cases there will bemultiple tags per context), though they are isomorphic.The new tag-matching semantics are: when walking up the stack, uponreaching a `try_call`, evaluate catch-clauses in listed order. A`context` clause sets the current context. A `tagN: block(...)` clauseattempts to match the throwing exception against `tagN`, *evaluated inthe current context*, and branches to the named block if it matches. A`default: block(...)` always branches to the named block.Note that this lets us assume less about tags than before, and thisparticularly manifests in the changes to the inliner. Whereas before,`tagN` is `tagN` and an inner handler for that tag shadows an outerhandler (that is, tags always alias if identical indices); and whereasbefore, `tagN` is not `tagM` and so we can order the tags arbitrarily(that is, tags never alias if non-identical indices); now any two statictag indices may or may not alias depending on the dynamic context ofeach. Or, even in the same context, two may alias, because we leave thematch-predicate as an unspecified (user-chosen) algorithm duringunwinding. (This mirrors the reality that, for example, a Wasm instancemay import two tags, and dynamically these tags may be equal ordifferent at runtime, even instantiation-to-instantiation.) Cranelift'sonly job is to faithfully carry the list of contexts and tags through tothe compiled-code metadata; and to ensure that they remain in the orderthey were specified in the CLIF.This PR introduces the Cranelift-level feature, and it will be used ina subsequent PR that introduces Wasm exception handling. Because ofthat, I've opted not to update the clif-utils runtest "runtime" to readout contexts and do something with them -- we will have plenty of testcoverage via a bunch of Wasm tests for corner cases such as the above.This PR does include filetests that show that contexts are carriedthrough to spillslots and those appear in the metadata.Fixes #11285. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.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/ir/dfg.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/ir/dfg.rs

703871a2 - Enable the `useless_conversion` Clippy lint (#10838)

Tue, 27 May 2025 16:49:22 +0000

Enable the `useless_conversion` Clippy lint (#10838)* Enable the `useless_conversion` Clippy lintWe've got lots of types in Wasmtime and convert between them quite alot, but often over time conversions become unnecessary throughrefactorings or similar. This will hopefully enable us to clean up someconversions as they come up to try to have as few as possible ideally.* Review comments List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.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/ir/dfg.rs

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

94ec88ea - Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)

Tue, 08 Apr 2025 00:02:16 +0000

Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)* Cranelift: initial try_call / try_call_indirect (exception) support.This PR adds `try_call` and `try_call_indirect` instructions, andlowerings on four of five ISAs (x86-64, aarch64, riscv64, pulley; s390xhas its own non-shared ABI code that will need separate work).It extends CLIF to support these instructions as new kinds of branches,and extends block-calls to accept `retN` and `exnN` block-call args thatcarry the normal return values or exception payloads (respectively) intothe appropriate successor blocks.It wires up the "normal return path" so that it continues to work.It updates the ABI so that unwinding is possible without an initialregister state at throw: specifically, as per our RFC, all registers areclobbered. It also includes metadata in the `MachBuffer` that describesexception-catch destinations. However, no unwinder exists to interpretthese catch-destinations yet, so they are untested.* Add try_call_indirect lowering as well. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

4f52f294 - Enable some more 2024 migration lints (#9962)

Thu, 09 Jan 2025 18:17:44 +0000

Enable some more 2024 migration lints (#9962)Most don't produce many warnings except for `rust-2024-incompatible-pat`which required removal of a number of `ref` and `ref mut` keywordsthroughout the workspace. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

9fc41bae - Convert `TrapCode` to a single byte (#9338)

Tue, 01 Oct 2024 18:06:33 +0000

Convert `TrapCode` to a single byte (#9338)* Convert `TrapCode` to a single byteThis commit refactors the representation of`cranelift_codegen::ir::TrapCode` to be a single byte. The previousenumeration is replaced with an opaque byte-sized structure. Previousvariants that Cranelift uses internally are now associated `const`values on `TrapCode` itself. For example `TrapCode::IntegerOverflow` isnow `TrapCode::INTEGER_OVERFLOW`. All non-Cranelift traps are nowremoved and exclusively live in the `wasmtime-cranelift` crate now.The representation of a `TrapCode` is now:* 0 - invalid, used in `MemFlags` for "no trap code"* 1..256-N - user traps* 256-N..256 - built-in Cranelift traps (it uses N of these)This enables embedders to have 255-N trap codes which is more thanenough for Wasmtime for example. Cranelift reserves a few built-in codesfor itself which shouldn't eat too much into the trap space.Additionally if Cranelift needs to grow a new trap it can do so prettyeasily too.The overall intent of this commit is to reduce the coupling of Wasmtimeand Cranelift further and generally refactor Wasmtime to use user trapsmore often. This additionally shrinks the size of `TrapCode` for storagein various locations, notably it can now infallibly be representedinside of a `MemFlags`.Closes #9310* Fix some more tests* Fix more tests* Fix even more tests* Review comments* Fix tests* Fix rebase conflict* Update test expectations List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

d6713c50 - Update nightly in CI to latest (#9195)

Tue, 03 Sep 2024 17:31:50 +0000

Update nightly in CI to latest (#9195)Additionally address some new warnings that are cropping up throughoutthe codebase. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

4df85c50 - Cranelift: Add an `is_safepoint` predicate to `Opcode` (#9066)

Fri, 02 Aug 2024 19:07:53 +0000

Cranelift: Add an `is_safepoint` predicate to `Opcode` (#9066) List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

0c0153c1 - Enforce `clippy::clone_on_copy` for the workspace (#9025)

Sat, 27 Jul 2024 01:11:06 +0000

Enforce `clippy::clone_on_copy` for the workspace (#9025)* Derive `Copy` for `Val`* Fix `clippy::clone_on_copy` for the whole repo* Enforce `clippy::clone_on_copy` for the workspace* fix some more clippy::clone_on_copy that got missed List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

59de3a32 - Cranelift: Allow CLIF frontends to define their own stack maps (#8728)

Fri, 07 Jun 2024 04:05:56 +0000

Cranelift: Allow CLIF frontends to define their own stack maps (#8728)Tracking GC references and producing stack maps is a significant amount ofcomplexity in `regalloc2`.At the same time, GC reference value types are pretty annoying to deal with inCranelift itself. We know our `r64` is "actually" just an `i64` pointer, and wewant to do `i64`-y things with it, such as an `iadd` to compute a derivedpointer, but `iadd` only takes integer types and not `r64`s. We investigatedloosening that restriction and it was way too painful given the way that CLIFtype inference and its controlling type vars work. So to compute those derivedpointers, we have to first `bitcast` the `r64` into an `i64`. This isunfortunate in two ways. First, because of arcane interactions between registerallocation constraints, stack maps, and ABIs this involves inserting unnecessaryregister-to-register moves in our generated code which hurts binary size andperformance ever so slightly. Second, and much more seriously, this is a seriousfootgun. If a GC reference isn't an `r64` right now, then it will not appear instack maps, and failure to record a live GC reference in a stack map means thatthe collector could reclaim the object while you are still using it, leading touse-after-free bugs! Very bad. And the mid-end needs to know*not* to GVN these bitcasts or else we get similar bugs (seehttps://github.com/bytecodealliance/wasmtime/pull/8317).Overall GC references are a painful situation for us today.This commit is the introduction of an alternative. (Note, though, that we aren'tquite ready to remove the old stack maps infrastructure just yet.)Instead of preserving GC references all the way through the whole pipeline andcomputing live GC references and inserting spills at safepoints for stack mapsall the way at the end of that pipeline in register allocation, theCLIF-producing frontend explicitly generates its own stack slots and spills forsafepoints. The only thing the rest of the compiler pipeline needs to know isthe metadata required to produce the stack map for the associated safepoint. Wecan completely remove `r32` and `r64` from Cranelift and just use plain `i32`and `i64` values. Or `f64` if the runtime uses NaN-boxing, which the old stackmaps system did not support at all. Or 32-bit GC references on a 64-bit target,which was also not supported by the old system. Furthermore, we *cannot* getmiscompiles due to GVN'ing bitcasts that shouldn't be GVN'd because there aren'tany bitcasts hiding GC references from stack maps anymore. And in the case of amoving GC, we don't need to worry about the mid-end doing illegal code motionacross calls that could have triggered a GC that invalidated the moved GCreference because frontends will reload their GC references from the stack slotsafter the call, and that loaded value simply isn't a candidate for GVN with theprevious version. We don't have to worry about those bugs by construction.So everything gets a lot easier under this new system.But this commit doesn't mean we are 100% done and ready to transition to the newsystem, so what is actually in here?* CLIF producers can mark values as needing to be present in a stack map if theyare live across a safepoint in `cranelift-frontend`. This is the`FunctionBuilder::declare_needs_stack_map` method.* When we finalize the function we are building, we do a simple, single-passliveness analysis to determine the set of GC references that are live at eachsafepoint, and then we insert spills to explicit stack slots just before thesafepoint. We intentionally trade away the precision of a fixed-point livenessanalysis for the speed and simplicity of a single-pass implementation.* We annotate the safepoint with the metadata necessary to construct itsassociated stack map. This is the new`cranelift_codegen::ir::DataFlowGraph::append_user_stack_map_entry` method andall that stuff.* These stack map entries are part of the CLIF and can be roundtripped throughprinting and parsing CLIF.* Each stack map entry describes a GC-managed value that is on the stack and howto locate it: its type, the stack slot it is located within, and the offsetwithin that stack slot where it resides. Different stack map entries for thesame safepoint may have different types or a different width from the target'spointer.Here is what is *not* handled yet, and left for future follow up commits:* Lowering the stack map entries' locations from symbolic stack slot and offsetpairs to physical stack frame offsets after register allocation.* Coalescing and aggregating the safepoints and their raw stack map entries intoa compact PC-to-stack-map table during emission.* Supporting moving GCs. Right now we generate spills into stack slots for liveGC references just before safepoints, but we don't reload the GC references fromthe stack upon their next use after the safepoint. This involves rewriting usesof the old, spilled values which could be a little finicky, but we think we havea good approach.* Port Wasmtime over to using this new stack maps system.* Removing the old stack map system, including `r{32,64}` from Cranelift and GCreference handling from `regalloc2`. (For the time being, the new systemgenerally refers to "user stack maps" to disambiguate from the old system whereit might otherwise be confusing.) If we wanted to remove the old system now,that would require us to also port Wasmtime to the new system now, and we'd endup with a monolithic PR. Better to do this incrementally and temporarily havethe old and in-progress new system overlap for a short period of time.Co-authored-by: Trevor Elliott List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

0e9121da - Fix some typos (#8641)

Thu, 16 May 2024 23:21:22 +0000

Fix some typos (#8641)* occurred* winch typos* tests typos* cli typos* fuzz typos* examples typos* docs typos* crates/wasmtime typos* crates/environ typos* crates/cranelift typos* crates/test-programs typos* crates/c-api typos* crates/cache typos* crates other typos* cranelift/codegen/src/isa typos* cranelift/codegen/src other typos* cranelift/codegen other typos* cranelift other typos* ci js typo* .github workflows typo* RELEASES typo* Fix clang-format documentation line---------Co-authored-by: Andrew Brown List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

d02f895f - cranelift: Minimize ways to manipulate instruction results (#8293)

Wed, 03 Apr 2024 17:45:52 +0000

cranelift: Minimize ways to manipulate instruction results (#8293)* cranelift: Minimize ways to manipulate instruction resultsIn particular, remove support for detaching/attaching/appendinginstruction results.The AliasAnalysis pass used detach_results, but leaked the detachedValueList; using clear_results instead is better.The verifier's `test_printing_contextual_errors` needed to get theverifier to produce an error containing a pretty-printed instruction,and did so by appending too many results. Instead, failing to append anyresults gets a similar error out of the verifier, without requiring thatwe expose the easy-to-misuse append_result method. However, `iconst` isnot a suitable instruction for this version of the test because itsresult type is its controlling type, so failing to create any resultscaused assertion failures rather than the desired verifier error. Iswitched to `f64const` which has a non-polymorphic type.The DFG's `aliases` test cleared both results of an instruction and thenreattached one of them. Since we have access to DFG internals in thesetests, it's easier to directly manipulate the relevant ValueList than touse these unsafe methods.The only other use of attach/append was in `make_inst_results_reusing`which decided which to use based on whether a particular result wassupposed to reuse an existing value. Inlining both methods thererevealed that they were nearly identical and could have most of theircode factored out.While I was looking at uses of `DataFlowGraph::results`, I alsosimplified replace_with_aliases a little bit.* Review comments List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs

82792146 - cranelift: Remove unused `old_signatures` field (#8294)

Wed, 03 Apr 2024 10:58:09 +0000

cranelift: Remove unused `old_signatures` field (#8294)This map has been unused since #3401. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/dfg.rs