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

9a340279 - Add more documentation to `ArgumentPurpose::StructArgument` (#8906)

Mon, 08 Jul 2024 21:00:34 +0000

Add more documentation to `ArgumentPurpose::StructArgument` (#8906)I was a bit unclear on what exactly it was for. I thought the u32 fieldcould also use some documentation to clarify its meaning. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

e852bcee - Remove ArgumentPurpose::StackLimit (#8700)

Tue, 28 May 2024 18:28:08 +0000

Remove ArgumentPurpose::StackLimit (#8700) List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.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/ir/extfunc.rs

729e2640 - A bunch of minor cleanups (#6767)

Tue, 25 Jul 2023 14:48:37 +0000

A bunch of minor cleanups (#6767)* Remove DisplayFunctionAnnotationsIt used to exist for printing the debuginfo value ranges with the clifir, but this no longer happens, so it is now useless.* Remove debug info collection from DummyEnvironmentThere are no remaining users of it* Remove ComparableSourceLocIt is unused* Move LabelValueLoc re-export out of the ir moduleIt encodes target specific information, so shouldn't be in the targetindependent ir module.* Remove RelocDistance dependency from ir::extfunc and ir::globalvalue List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

202d3af1 - Remove the unused sigid argument purpose (#5753)

Thu, 09 Feb 2023 17:18:39 +0000

Remove the unused sigid argument purpose (#5753) List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

3b6544dc - Fix warnings in `cranelift-codegen` docs builds (#5292)

Thu, 17 Nov 2022 21:13:24 +0000

Fix warnings in `cranelift-codegen` docs builds (#5292) List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

32a7593c - cranelift: Remove booleans (#5031)

Mon, 17 Oct 2022 23:00:27 +0000

cranelift: Remove booleans (#5031)Remove the boolean types from cranelift, and the associated instructions breduce, bextend, bconst, and bint. Standardize on using 1/0 for the return value from instructions that produce scalar boolean results, and -1/0 for boolean vector elements. Fixes #3205 Co-authored-by: Afonso Bordado Co-authored-by: Ulrich Weigand Co-authored-by: Chris Fallin List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

8a9b1a90 - Implement an incremental compilation cache for Cranelift (#4551)

Fri, 12 Aug 2022 16:47:43 +0000

Implement an incremental compilation cache for Cranelift (#4551)This is the implementation of https://github.com/bytecodealliance/wasmtime/issues/4155, using the "inverted API" approach suggested by @cfallin (thanks!) in Cranelift, and trait object to provide a backend for an all-included experience in Wasmtime. After the suggestion of Chris, `Function` has been split into mostly two parts: - on the one hand, `FunctionStencil` contains all the fields required during compilation, and that act as a compilation cache key: if two function stencils are the same, then the result of their compilation (`CompiledCodeBase`) will be the same. This makes caching trivial, as the only thing to cache is the `FunctionStencil`. - on the other hand, `FunctionParameters` contain the... function parameters that are required to finalize the result of compilation into a `CompiledCode` (aka `CompiledCodeBase`) with proper final relocations etc., by applying fixups and so on. Most changes are here to accomodate those requirements, in particular that `FunctionStencil` should be `Hash`able to be used as a key in the cache: - most source locations are now relative to a base source location in the function, and as such they're encoded as `RelSourceLoc` in the `FunctionStencil`. This required changes so that there's no need to explicitly mark a `SourceLoc` as the base source location, it's automatically detected instead the first time a non-default `SourceLoc` is set. - user-defined external names in the `FunctionStencil` (aka before this patch `ExternalName::User { namespace, index }`) are now references into an external table of `UserExternalNameRef -> UserExternalName`, present in the `FunctionParameters`, and must be explicitly declared using `Function::declare_imported_user_function`. - some refactorings have been made for function names: - `ExternalName` was used as the type for a `Function`'s name; while it thus allowed `ExternalName::Libcall` in this place, this would have been quite confusing to use it there. Instead, a new enum `UserFuncName` is introduced for this name, that's either a user-defined function name (the above `UserExternalName`) or a test case name. - The future of `ExternalName` is likely to become a full reference into the `FunctionParameters`'s mapping, instead of being "either a handle for user-defined external names, or the thing itself for other variants". I'm running out of time to do this, and this is not trivial as it implies touching ISLE which I'm less familiar with. The cache computes a sha256 hash of the `FunctionStencil`, and uses this as the cache key. No equality check (using `PartialEq`) is performed in addition to the hash being the same, as we hope that this is sufficient data to avoid collisions. A basic fuzz target has been introduced that tries to do the bare minimum: - check that a function successfully compiled and cached will be also successfully reloaded from the cache, and returns the exact same function. - check that a trivial modification in the external mapping of `UserExternalNameRef -> UserExternalName` hits the cache, and that other modifications don't hit the cache. - This last check is less efficient and less likely to happen, so probably should be rethought a bit. Thanks to both @alexcrichton and @cfallin for your very useful feedback on Zulip. Some numbers show that for a large wasm module we're using internally, this is a 20% compile-time speedup, because so many `FunctionStencil`s are the same, even within a single module. For a group of modules that have a lot of code in common, we get hit rates up to 70% when they're used together. When a single function changes in a wasm module, every other function is reloaded; that's still slower than I expect (between 10% and 50% of the overall compile time), so there's likely room for improvement. Fixes #4155. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

a4aa7258 - Remove some dead code from the abi code (#4653)

Tue, 09 Aug 2022 19:21:55 +0000

Remove some dead code from the abi code (#4653)These were originally used by the old backend framework as part of legalizing function signatures for the respective ABI. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.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/ir/extfunc.rs

43a86f14 - Remove more old backend ISA concepts (#3402)

Mon, 04 Oct 2021 08:36:12 +0000

Remove more old backend ISA concepts (#3402)This also paves the way for unifying TargetIsa and MachBackend, since now they map one to one. In theory the two traits could be merged, which would be nice to limit the number of total concepts. Also they have quite different responsibilities, so it might be fine to keep them separate. Interestingly, this PR started as removing RegInfo from the TargetIsa trait since the adapter returned a dummy value there. From the fallout, noticed that all Display implementations didn't needed an ISA anymore (since these were only used to render ISA specific registers). Also the whole family of RegInfo / ValueLoc / RegUnit was exclusively used for the old backend, and these could be removed. Notably, some IR instructions needed to be removed, because they were using RegUnit too: this was the oddball of regfill / regmove / regspill / copy_special, which were IR instructions inserted by the old regalloc. Fare thee well! List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

2fc964ea - Add serde serialization support for the full clif ir

Sat, 19 Dec 2020 15:32:46 +0000

Add serde serialization support for the full clif ir List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

a2bbb198 - Do value-extensions at ABI boundaries only when ABI requires it.

Wed, 04 Nov 2020 19:45:44 +0000

Do value-extensions at ABI boundaries only when ABI requires it.There has been some confusion over the meaning of the "sign-extend"(`sext`) and "zero-extend" (`uext`) attributes on parameters and returnvalues in signatures. According to the three implemented backends, theseattributes indicate that a value narrower than a full register shouldalways be extended in the way specified. However, they are much moreuseful if they mean "extend in this way if the ABI requires extending":only the ABI backend knows whether or not a particular ABI (e.g., x64SysV vs. x64 Baldrdash) requires extensions, while only the frontend(CLIF generator) knows whether or not a value is signed, so the two haveto work in concert.This is the result of some very helpful discussion in #2354 (thanks to@uweigand for raising the issue and @bjorn3 for helping to reason aboutit).This change respects the extension attributes in the above way, ratherthan unconditionally extending, to avoid potential performancedegradation as we introduce more extension attributes on signatures. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.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/ir/extfunc.rs

0d4fa6d3 - Fix review comments

Wed, 15 Jul 2020 17:19:07 +0000

Fix review comments List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

4431ac11 - Implement SystemV struct argument passing

Mon, 20 Apr 2020 10:01:53 +0000

Implement SystemV struct argument passing List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs

b2551bb4 - Make wasmtime_environ::Module serializable (#2005)

Fri, 10 Jul 2020 20:56:43 +0000

Make wasmtime_environ::Module serializable (#2005)* Define WasmType/WasmFuncType in the Cranelift * Make `Module` serializable List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/extfunc.rs