Changes in call_conv.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/isa/call_conv.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/isa/call_conv.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/isa/call_conv.rs

192f2fcd - Replace setjmp/longjmp usage in Wasmtime (#11592)

Mon, 08 Sep 2025 14:33:31 +0000

Replace setjmp/longjmp usage in Wasmtime (#11592)Since Wasmtime's inception it's used the `setjmp` and `longjmp`functions in C to implement handling of traps. While this solution waseasy to implement, relatively portable, and performant enough, there area number of downsides that have evolved over time to make this anunattractive approach in the long run:* Using `setjmp` fundamentally requires using C because Rust does not understand a function that returns twice. It's fundamentally unsound to invoke `setjmp` in Rust meaning that Wasmtime has forever needed a C compiler configured and set up to build. This notably means that `cargo check` cannot check other targets easily.* Using `longjmp` means that Rust function frames are unwound on the stack without running destructors. This is a dangerous operation of which we get no protection from the compiler about. Both frames entering wasm and frames exiting wasm are all skipped. Absolutely minimizing this has been beneficial for portability to platforms such as Pulley.* Currently the no_std implementation of Wasmtime requires embedders to provide `wasmtime_{setjmp,longjmp}` which is a thorn in the side of what is otherwise a mostly entirely independent implementation of Wasmtime.* There is a performance floor to using `setjmp` and `longjmp`. Calling `setjmp` requires using C but Wasmtime is otherwise written in Rust meaning that there's a Rust->C->Rust->Wasm boundary which fundamentally can't be inlined without cross-language LTO which is difficult to configure.* With the implementation of the WebAssembly exceptions proposal Wasmtime now has two means of unwinding the stack. Ideally Wasmtime would only have one, and the more general one is the method of exceptions.* Jumping out of a signal handler on Unix is tricky business. While we've made it work it's generally most robust of the signal handler simply returns which it now does.With all of that in mind the purpose of this commit is to replace thesetjmp/longjmp mechanism of handling traps with the recently implementedsupport for exceptions in Cranelift. That is intended to resolve all ofthe above points in one swoop.One point in particular though that's nice about setjmp/longjmp is thatunwinding the stack on a trap is an O(1) operation. For situations suchas stack overflow that's a particularly nice property to have as we canguarantee embedders that traps are a constant time (albeit somewhatexpensive with signals) operation. Exceptions naively require unwindingthe entire stack, and although frame pointers mean we're just traversinga linked list I wanted to preserve the O(1) property here nonetheless.To achieve this a solution is implemented where the array-to-wasm(host-to-wasm) trampolines setup state in `VMStoreContext` so looking upthe current trap handler frame is an O(1) operation. Namely the sp/fp/pcvalues for a `Handler` are stored inline.Implementing this feature required supportingrelocations-to-offsets-in-functions which was not previously supportedby Wasmtime. This required Cranelift refactorings such as #11570, #11585,and #11576. This then additionally required some more refactoring inthis commit which was difficult to split out as it otherwise wouldn't betested.Apart from the relocation-related business much of this change is aboutupdating the platform signal handlers to use exceptions instead oflongjmp to return. For example on Unix this means updating the`ucontext_t` with register values that the handler specifies. Windowsinvolves updating similar contexts, and macOS mach ports ended up notneeding too many changes.In terms of overall performance the relevant benchmark from thisrepository, compared to before this commit, is: sync/no-hook/core - host-to-wasm - typed - nop time: [10.552 ns 10.561 ns 10.571 ns] change: [−7.5238% −7.4011% −7.2786%] (p = 0.00 < 0.05) Performance has improved.Closes #3927cc #10923prtest:full List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

3c3fb35b - Clarify docs around exceptions in Cranelift (#11601)

Wed, 03 Sep 2025 20:37:59 +0000

Clarify docs around exceptions in Cranelift (#11601)* Clarify docs around exceptions in CraneliftThis is a result of today's Cranelift meeting with some of my questionsaround the ABI bits here and there. Notably:* Cranelift is audited and now documented to always consider the callee calling convention in `try_call`, disregarding the caller calling convention.* Wasmtime's exception throw now explicitly names the `tailcc` in the name to indicate that it's only compatible with the tail calling convention.* The verifier test for exceptions is expanded with a few more cases here and there that I could think of.* Backends now assert that the size of the calling-convention list of payload types is the same as the size of the list of registers the backend places results into.* Fix a typo List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.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/isa/call_conv.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/isa/call_conv.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/isa/call_conv.rs

a659b5a9 - Couple of cleanups to the ABI computation (#9253)

Mon, 16 Sep 2024 16:20:47 +0000

Couple of cleanups to the ABI computation (#9253)* Remove WasmtimeSystemV call convIt is no longer used by Wasmtime* Remove CallConv::extends_* methodsThey all match only a single call conv anyway.* Avoid isa:: prefix for referencing CallConv where possible* Update callconv list in the clif ir reference* Use push_non_formal where expected List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

86e73507 - cranelift: Add a winch calling convention (#8056)

Fri, 08 Mar 2024 18:25:46 +0000

cranelift: Add a winch calling convention (#8056)* Add a winch calling convention to cranelift* Add some tests to exercise the winch calling convention* Enable fuzzing for the winch calling convention* Share the list of clobbers with the tail calling convention* Fix the doc build List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

9ec02f9d - Decouple `serde` from its `derive` crate (#6917)

Tue, 29 Aug 2023 16:02:06 +0000

Decouple `serde` from its `derive` crate (#6917)By not activating the `derive` feature on `serde`, the compilation speedcan be improved by a lot. This is because `serde` can then compile inparallel to `serde_derive`, allowing it to finish compilation possiblyeven before `serde_derive`, unblocking all the crates waiting for`serde` to start compiling much sooner.As it turns out the main deciding factor for how long the compile time of aproject is, is primarly determined by the depth of dependencies ratherthan the width. In other words, a crate's compile times aren't affectedby how many crates it depends on, but rather by the longest chain ofdependencies that it needs to wait on. In many cases `serde` is part ofthat long chain, as it is part of a long chain if the `derive` featureis active:`proc-macro2` compile build script > `proc-macro2` run build script >`proc-macro2` > `quote` > `syn` > `serde_derive` > `serde` >`serde_json` (or any crate that depends on serde)By decoupling it from `serde_derive`, the chain is shortened and compiletimes get much better.Check this issue for a deeper elaboration:https://github.com/serde-rs/serde/issues/2584For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s whencompiling in `release` mode. This is because wasmtime through `gimli`has a dependency on `indexmap` which can only start compiling when`serde` is finished, which you want to happen as early as possible sosome of wasmtime's dependencies can start compiling.To measure the full effect, the dependencies can't by themselvesactivate the `derive` feature. I've upstreamed a patch for`fxprof-processed-profile` which was the only dependency that activatedit for `wasmtime` (not yet published to crates.io). `wasmtime-cli` andco. may need patches for their dependencies to see a similarimprovement. List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

39c96c7a - Remove Wasmtime ABIs from Cranelift (#6649)

Wed, 28 Jun 2023 18:53:19 +0000

Remove Wasmtime ABIs from Cranelift (#6649)* Remove Wasmtime ABIs from CraneliftThis commit removes the `Wasmtime*` family of ABIs from Cranelift. Thesewere originally added to support multi-value in Wasmtime via the`TypedFunc` API, but they should now no longer be necessary. In generalthis is a higher-level Wasmtime concern than something all backends ofCranelift should have to deal with.Today with recent refactorings it's possible to remove the reliance onABI details for multi-value and instead codify it directly into theCranelift IR generated. For example wasm calls are able to have a"purely internal" ABI which Wasmtime's Rust code doesn't see at all, andthe Rust code only interacts with the native ABI. The native ABI isredefined to be what the previous Wasmtime ABIs were, which is to returnthe first of a 2+ value return through a register (native return value)and everything else through a return pointer.* Remove some wasmtime_system_v usage in tests* Add back WasmtimeSystemV for s390x* Fix some docs and references in winch* Fix another doc link List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

e105aa38 - Cranelift: Get non-tail calls working for the "tail" calling convention (#6500)

Fri, 09 Jun 2023 18:34:23 +0000

Cranelift: Get non-tail calls working for the "tail" calling convention (#6500)Co-authored-by: Jamey Sharp List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

bdfb7465 - Cranelift: Introduce the `return_call` and `return_call_indirect` instructions (#5679)

Wed, 01 Feb 2023 21:20:35 +0000

Cranelift: Introduce the `return_call` and `return_call_indirect` instructions (#5679)* Cranelift: Introduce the `tail` calling convention This is an unstable-ABI calling convention that we will eventually use to support Wasm tail calls. Co-Authored-By: Jamey Sharp * Cranelift: Introduce the `return_call` and `return_call_indirect` instructions These will be used to implement tail calls for Wasm and any other language targeting CLIF. The `return_call_indirect` instruction differs from the Wasm instruction of the same name by taking a native address callee rather than a Wasm function index. Co-Authored-By: Jamey Sharp * Cranelift: Implement verification rules for `return_call[_indirect]` They must: * have the same return types between the caller and callee, * have the same calling convention between caller and callee, * and that calling convention must support tail calls. Co-Authored-By: Jamey Sharp * cargo fmt --------- Co-authored-by: Jamey Sharp List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

43f17652 - Cranellift: remove Baldrdash support and related features. (#4571)

Tue, 02 Aug 2022 19:37:56 +0000

Cranellift: remove Baldrdash support and related features. (#4571)* Cranellift: remove Baldrdash support and related features. As noted in Mozilla's bugzilla bug 1781425 [1], the SpiderMonkey team has recently determined that their current form of integration with Cranelift is too hard to maintain, and they have chosen to remove it from their codebase. If and when they decide to build updated support for Cranelift, they will adopt different approaches to several details of the integration. In the meantime, after discussion with the SpiderMonkey folks, they agree that it makes sense to remove the bits of Cranelift that exist to support the integration ("Baldrdash"), as they will not need them. Many of these bits are difficult-to-maintain special cases that are not actually tested in Cranelift proper: for example, the Baldrdash integration required Cranelift to emit function bodies without prologues/epilogues, and instead communicate very precise information about the expected frame size and layout, then stitched together something post-facto. This was brittle and caused a lot of incidental complexity ("fallthrough returns", the resulting special logic in block-ordering); this is just one example. As another example, one particular Baldrdash ABI variant processed stack args in reverse order, so our ABI code had to support both traversal orders. We had a number of other Baldrdash-specific settings as well that did various special things. This PR removes Baldrdash ABI support, the `fallthrough_return` instruction, and pulls some threads to remove now-unused bits as a result of those two, with the understanding that the SpiderMonkey folks will build new functionality as needed in the future and we can perhaps find cleaner abstractions to make it all work. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1781425 * Review feedback. * Fix (?) DWARF debug tests: add `--disable-cache` to wasmtime invocations. The debugger tests invoke `wasmtime` from within each test case under the control of a debugger (gdb or lldb). Some of these tests started to inexplicably fail in CI with unrelated changes, and the failures were only inconsistently reproducible locally. It seems to be cache related: if we disable cached compilation on the nested `wasmtime` invocations, the tests consistently pass. * Review feedback. List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

51edea9e - cranelift: introduce a new WasmtimeAppleAarch64 calling convention

Tue, 01 Jun 2021 09:29:52 +0000

cranelift: introduce a new WasmtimeAppleAarch64 calling conventionThe previous choice to use the WasmtimeSystemV calling convention forapple-aarch64 devices was incorrect: padding of arguments wasincorrectly computed. So we have to use some flavor of the apple-aarch64ABI there.Since we want to support the wasmtime custom convention for multiplereturns on apple-aarch64 too, a new custom Wasmtime calling conventionwas introduced to support this. List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

195bf0e2 - Fully support multiple returns in Wasmtime (#2806)

Wed, 07 Apr 2021 17:34:26 +0000

Fully support multiple returns in Wasmtime (#2806)* Fully support multiple returns in Wasmtime For quite some time now Wasmtime has "supported" multiple return values, but only in the mose bare bones ways. Up until recently you couldn't get a typed version of functions with multiple return values, and never have you been able to use `Func::wrap` with functions that return multiple values. Even recently where `Func::typed` can call functions that return multiple values it uses a double-indirection by calling a trampoline which calls the real function. The underlying reason for this lack of support is that cranelift's ABI for returning multiple values is not possible to write in Rust. For example if a wasm function returns two `i32` values there is no Rust (or C!) function you can write to correspond to that. This commit, however fixes that. This commit adds two new ABIs to Cranelift: `WasmtimeSystemV` and `WasmtimeFastcall`. The intention is that these Wasmtime-specific ABIs match their corresponding ABI (e.g. `SystemV` or `WindowsFastcall`) for everything *except* how multiple values are returned. For multiple return values we simply define our own version of the ABI which Wasmtime implements, which is that for N return values the first is returned as if the function only returned that and the latter N-1 return values are returned via an out-ptr that's the last parameter to the function. These custom ABIs provides the ability for Wasmtime to bind these in Rust meaning that `Func::wrap` can now wrap functions that return multiple values and `Func::typed` no longer uses trampolines when calling functions that return multiple values. Although there's lots of internal changes there's no actual changes in the API surface area of Wasmtime, just a few more impls of more public traits which means that more types are supported in more places! Another change made with this PR is a consolidation of how the ABI of each function in a wasm module is selected. The native `SystemV` ABI, for example, is more efficient at returning multiple values than the wasmtime version of the ABI (since more things are in more registers). To continue to take advantage of this Wasmtime will now classify some functions in a wasm module with the "fast" ABI. Only functions that are not reachable externally from the module are classified with the fast ABI (e.g. those not exported, used in tables, or used with `ref.func`). This should enable purely internal functions of modules to have a faster calling convention than those which might be exposed to Wasmtime itself. Closes #1178 * Tweak some names and add docs * "fix" lightbeam compile * Fix TODO with dummy environ * Unwind info is a property of the target, not the ABI * Remove lightbeam unused imports * Attempt to fix arm64 * Document new ABIs aren't stable * Fix filetests to use the right target * Don't always do 64-bit stores with cranelift This was overwriting upper bits when 32-bit registers were being stored into return values, so fix the code inline to do a sized store instead of one-size-fits-all store. * At least get tests passing on the old backend * Fix a typo * Add some filetests with mixed abi calls * Get `multi` example working * Fix doctests on old x86 backend * Add a mixture of wasmtime/system_v tests List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

6e6713ae - cranelift: add support for the Mac aarch64 calling convention

Thu, 18 Mar 2021 14:21:40 +0000

cranelift: add support for the Mac aarch64 calling conventionThis bumps target-lexicon and adds support for the AppleAarch64 callingconvention. Specifically for WebAssembly support, we only have to worryabout the new stack slots convention. Stack slots don't need to be atleast 8-bytes, they can be as small as the data type's size. Forinstance, if we need stack slots for (i32, i32), they can be located atoffsets (+0, +4). Note that they still need to be properly aligned onthe data type they're containing, though, so if we need stack slots for(i32, i64), we can't start the i64 slot at the +4 offset (it must startat the +8 offset).Added one test that was failing on the Mac M1, as well as other testsstressing different yet similar situations. List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

835db11b - Support for SpiderMonkey's "Wasm ABI 2020".

Tue, 22 Sep 2020 23:53:06 +0000

Support for SpiderMonkey's "Wasm ABI 2020".As part of a Wasm JIT update, SpiderMonkey is changing its internalWebAssembly function ABI. The new ABI's frame format includes "callerTLS" and "callee TLS" slots. The details of where these come from arenot important; from Cranelift's point of view, the only relevantrequirement is that we have two on-stack args that are always present(offsetting other on-stack args), and that we define special argumentpurposes so that we can supply values for these slots.Note that this adds a *new* ABI (a variant of the Baldrdash ABI) becausewe do not want to tightly couple the landing of this PR to the landingof the changes in SpiderMonkey; it's better if both the old and newbehavior remain available in Cranelift, so SpiderMonkey can continue tovendor Cranelift even if it does not land (or backs out) the ABI change.Furthermore, note that this needs to be a Cranelift-level change (i.e.cannot be done purely from the translator environment implementation)because the special TLS arguments must always go on the stack, whichwould not otherwise happen with the usual argument-placement logic; andthere is no primitive to push a value directly in CLIF code (the notionof a stack frame is a lower-level concept). List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs

694af3ae - machinst x64: implement float Floor/Ceil/Trunc/Nearest as VM calls;

Tue, 21 Jul 2020 16:04:33 +0000

machinst x64: implement float Floor/Ceil/Trunc/Nearest as VM calls; List of files: /wasmtime-44.0.1/cranelift/codegen/src/isa/call_conv.rs