Changes in mod.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/verifier/mod.rs

c3c2ee20 - Cranelift: preserve_all: disallow return values. (#12447)

Tue, 27 Jan 2026 18:50:47 +0000

Cranelift: preserve_all: disallow return values. (#12447)In #12399 a fuzzbug uncovered an issue whereby a function with`preserve_all` and with many return values cannot be called, because`emit_retval_loads` cannot codegen memory-to-memory moves (from on-stackreturn value slots directly to spillslots) without atemporary/clobberable register, and `preserve_all` implies no suchregisters exist.I thought about trying to support this by shuffling registers -- such acase implies many return values, and at least some of them will be inregisters, so we might be able to temporarily spill one of those and useit as a scratch to move other values memory-to-memory. But thecomplexity doesn't seem worthwhile, and this path is not actually neededat the moment.Thinking more broadly, anyone using `preserve_all` for hooks meant tominimally perturb register state will likely not want to use many returnvalues anyway (that defeats the point). We could allow *one* returnvalue, with the knowledge that this always fits in a register in ourexisting ABIs, but that also feels somewhat arbitrary, and I could makethe argument that "preserve all" should really mean preserve *all*.Someone wanting to return a value anyway from such a hook could useindirect means (pass in a pointer to a stackslot, for example). I'mhappy to tweak this limit if others have more thoughts, however.Fixes #12399. List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.rs

0889323a - cranelift-codegen: rename most uses of std to core and alloc (#12237)

Sat, 03 Jan 2026 00:54:48 +0000

cranelift-codegen: rename most uses of std to core and alloc (#12237)* rename most std uses to core and alloc* cargo fmt List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.rs

87ed3b60 - Cranelift: make all non-tail, non-indirect calls patchable, and rename patchable ABI to `preserve_all`. (#12160)

Mon, 15 Dec 2025 23:29:06 +0000

Cranelift: make all non-tail, non-indirect calls patchable, and rename patchable ABI to `preserve_all`. (#12160)* Cranelift: make all non-tail, non-indirect calls patchable, and rename patchable ABI to `preserve_all`.As discussed in this week's Cranelift meeting, we've discovered a needto generalize the `patchable_call` mechanism and corresponding`patchable` ABI slightly. In particular, we will need patchable`try_call` callsites as well in order to allow breakpoint handlers tothrow exceptions (desirable functionality eventually) and have this workin the presence of inlining. Also, it's just a nice generalization tosay that patchability is an orthogonal dimension to the call ABI and theother restrictions we initially imposed, and works as long as the basicrequirement (no return values) is met.This also renames the `patchable` ABI to `preserve_all`, to make itclear that its purpose is actually orthogonal, and it can be usedindependently of patchable callsites. It also deletes the `cold` ABI,which never actually did anything and is misleading in the presence ofan actual cold-ish (subzero temperature, actually) ABI like`preserve_all`.* Review feedback. List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.rs

c00e9ea2 - Cranelift: add patchable call instructions. (#12101)

Tue, 02 Dec 2025 00:59:15 +0000

Cranelift: add patchable call instructions. (#12101)* Cranelift: add patchable call instructions.The new `patchable_call` CLIF instruction pairs with the `patchable`ABI, and emits a callsite with one new key property: the MachBuffercarries metadata that describes exactly which byte range to "NOP out"(overwrite with NOP instructions) to disable that callsite. Doing so issemantically valid and explicitly supported.This enables patching of code at runtime to dynamically turn on and offfeatures such as instrumentation or debugging hooks. We plan to use thisto implement breakpoints in Wasmtime's guest debugging support.As part of this change, I added a notion of "unit of NOP bytes" to theMachBuffer so that the consumer (e.g., Wasmtime's Cranelift-based codecompilation pipeline and metadata-producing logic) can handle patchablecallsites without any other special knowledge of the ISA.For the "real metal" ISAs there are perfectly well-defined NOPs to use,but for Pulley, where all opcodes are assigned at compile time by macromagic, I explicitly defined NOP as opcode byte 0 by moving `Nop`'sdefinition to the top of the list and adding a unit test asserting itsencoding.A design note: in principle it would be possible, as an alternative, totreat "patchability" as an orthogonal dimension of all callsites, andemit the metadata describing the instruction-offset range for anycallsite with the flag set. The only truly necessary semanticrestriction is that there are no return values (because if we turn thecallsite off, nothing writes to them); we could support patchability forother ABIs and for the other kinds of call instructions. The `patchable`ABI would then be better described as something like the "no clobbersABI". I opted not to generalize in this way because it creates someless-tested corners and the generalized form, at least at the MachInstlevel, is not really much simpler in the end.A testing note: I opted not to implement actual code patching in the`cranelift-tools` filetest runner and test patching callsites in/out viasome actuation (e.g. a magic hostcall, like we do for throws) because(i) that's a lot of new plumbing and (ii) we are going to test this veryshortly in Wasmtime anyway and (iii) the correctness (or not) of thelocation-and-length metadata is easy enough to verify in thedisassemblies in the compile-tests.* Review feedback: remove dependence on (and test for) NOP being the literal byte 0. List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.rs

08927ba9 - Cranelift: add a "patchable call" ABI. (#12061)

Sat, 22 Nov 2025 02:31:23 +0000

Cranelift: add a "patchable call" ABI. (#12061)This ABI is intended for use in scenarios where we want a verylightweight callsite that can be turned on and off by patching in oneinstruction. (The actual patchable call instruction is not in this PR;that will be a separate PR.)The idea is that we define a call to clobber *no* registers -- noteven the arguments! And we restrict signatures such that on all of oursupported architectures, all arguments go into registers only. Thosetwo requirements together mean that all callsites for this ABI shouldhave only a raw call instruction, with no loads/stores to stackslots;and have the minimum possible impact on regalloc, by only imposingconstraints on args to ensure they are in certain registers but notaltering those registers.Given this, we could implement, e.g., breakpoints with patchablecallsites (off by default) at every sequence point in compiledcode. In a typical use-case with Wasmtime-compiled Wasm, that wouldput a bunch of uses of vmctx constrained to the first argumentregister in every code path, but vmctx likely already sits there mostof the time anyway (for any call to other Wasm functions or forlibcalls). Thus, the impact is just the one instruction and nothingelse.This PR adds the calling convention itself and tests that showthat *two* consecutive callsites can be compiled with no registersetup re-occurring from one call to the next (thus demonstrating noclobbers). List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.rs

a3d6e407 - Cranelift: add debug tag infrastructure. (#11768)

Mon, 06 Oct 2025 19:38:03 +0000

Cranelift: add debug tag infrastructure. (#11768)* Cranelift: add debug tag infrastructure.This PR adds *debug tags*, a kind of metadata that can attach to CLIFinstructions and be lowered to VCode instructions and as metadata onthe produced compiled code. It also adds opaque descriptor blobscarried with stackslots. Together, these two features allow decoratingIR with first-class debug instrumentation that is properly preservedby the compiler, including across optimizations andinlining. (Wasmtime's use of these features will come in followupPRs.)The key idea of a "debug tag" is to allow the Cranelift embedder toexpress whatever information it needs to, in a format that is opaqueto Cranelift itself, except for the parts that need translation duringlowering. In particular, the `DebugTag::StackSlot` variant getstranslated to a physical offset into the stackframe in the compiledmetadata output. So, for example, the embedder can emit a tagreferring to a stackslot, and another describing an offset in thatstackslot.The debug tags exist as a *sequence* on any given instruction; themeaning of the sequence is known only to the embedder, *except* thatduring inlining, the tags for the inlining call instruction areprepended to the tags of inlined instructions. In this way, acanonical use-case of tags as describing original source-languageframes can preserve the source-language view even when multiplefunctions are inlined into one.The descriptor on a stackslot may look a little odd at first, but itspurpose is to allow serializing some description ofstackslot-contained runtime user-program data, in a way that is firmlyattached to the stackslot. In particular, in the face of inlining,this descriptor is copied into the inlining (parent) function from theinlined function when the stackslot entity is copied; no othermetadata outside Cranelift needs to track the identity of stackslotsand know about that motion. This fits nicely with the ability of tagsto refer to stackslots; together, the embedder can annotateinstructions as having certain state in stackslots, and describe theformat of that state per stackslot.This infrastructure is tested with some compile-tests now;testing of the interpretation of the metadata output will come withend-to-end debug instrumentation tests in a followup PR.* Review feedback: add back sequence points and enforce tags only on sequence points or calls.* Use Vecs for debug metadata in MachBuffer to avoid SmallVec size penalty in not-used case.* Review feedback: switch from inlined stackslot descriptor blobs to u64 keys. List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.rs

4c01ee2f - Cranelift: add get_exception_handler_address. (#11629)

Fri, 05 Sep 2025 22:41:46 +0000

Cranelift: add get_exception_handler_address. (#11629)* Cranelift: add get_exception_handler_address.This is designed to enable applications such as #11592 that usealternative unwinding mechanisms that may not necessarily want to walk astack and look up exception tables. The idea is that whenever it wouldbe valid to resume to an exception handler that is active on the stack,we can provide the same PC as a first-class runtime value that would befound in the exception table for the given handler edge. A "custom"resume step can then use this PC as a resume-point as long as it followsthe relevant exception ABI (i.e.: restore SP, FP, any other savedregisters that the exception ABI specifies, and provide appropriatepayload value(s)).Handlers are associated with edges out of `try_call`s (or`try_call_indirect`s); and edges specifically, not blocks, because therecould be multiple out-edges to one block. The instruction thus takes theblock that contains the try-call and an immediate that indexes itsexceptional edges.This CLIF instruction required a bit of infrastructure to (i) allownaming raw blocks, not just block calls, as instruction arguments, and(ii) allow getting the MachLabel for any other lowered block duringlowering. But given that, the lowerings themselves are straightforwarduses of MachBuffer labels to fix-up PC-relative address-loadinginstructions (e.g., `LEA` or `ADR` or `AUIPC`+`ADDI`).* Review feedback.* Review feedback: more tests. List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.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/verifier/mod.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/verifier/mod.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/verifier/mod.rs

d3e7548e - Enable the `from_over_into` Clippy lint (#10837)

Tue, 27 May 2025 15:15:37 +0000

Enable the `from_over_into` Clippy lint (#10837)This requires implementing `From for U` instead of `Into for T`.While both trait impls are valid the `From` one is more useful becauseit implies `Into` and additionally gives you `From`. This additionallythen migrates the existing codebase to using the new style of impls. List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.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/verifier/mod.rs

3932e8f1 - Some fixes for try_call (#10593)

Thu, 17 Apr 2025 16:16:41 +0000

Some fixes for try_call (#10593)* Fix cranelift-frontend handling of try_call* Implement eliminate_unreachable_code for exception tables* Ensure try_call is considered a memory fence* Don't error on try_call in the verifier if no TargetIsa is passed* Don't clobber all registers for try_call unless the tail call conv is usedThis way other consumers of Cranelift don't have to pay the cost of theway Wasmtime will implement unwinding on exceptions.* Allow SystemV call conv with try_call List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.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/verifier/mod.rs

fc5fc675 - Add some more context to the CLIF verifier (#10410)

Mon, 17 Mar 2025 19:53:45 +0000

Add some more context to the CLIF verifier (#10410)Helps when debugging verifier failures. List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.rs

9afc64b4 - Introduce verification of integer address type widths. (#10209)

Sat, 15 Feb 2025 02:22:19 +0000

Introduce verification of integer address type widths. (#10209)* cranelift/codegen/verifier: Add verification of pointer width (#10118)This adds a check to load that confirms the pointer width is as expectedaccording to the target.* cranelift/verifier: Add load pointer width verification.Also clarify width of integer address type and unit tests that checkthe new verifier rule.* cranelift/filetests: Split out 64 and 32 bit loads.Makes unit test pass with the verifier checking the load addresssize.* cranelift/verifier: Add address verification to more instructions.Also adds unit tests to ensure problematic cases are detected.* cranelift/verifier: Change wording, restructure arms. List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.rs

1bb71d31 - Compute dominator tree using semi-NCA algorithm (#9603)

Thu, 09 Jan 2025 16:23:50 +0000

Compute dominator tree using semi-NCA algorithm (#9603)* Add dominator tree computed using semi-NCA algorithm.* Add dominator tree fuzz target* Move previous version of dominator tree to a separate file* Improve comments.* Use the new dominator tree in verifier.* Remove unused `iterators` module. List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.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/verifier/mod.rs

dc00bb61 - Refactor `Ieee{16,32,64,128}` (#8982)

Thu, 25 Jul 2024 22:55:16 +0000

Refactor `Ieee{16,32,64,128}` (#8982) List of files: /wasmtime-44.0.1/cranelift/codegen/src/verifier/mod.rs