Optimize the implementation of `ref.func` by alexcrichton · Pull Request #14683 · bytecodealliance/wasmtime

alexcrichton · 2026-10-12T20:25:48Z

This PR is a series of commits which ends up optimizing the ref.func implementation within Wasmtime to notably not require a hostcall and additionally not require any function lookups within the compiled function tables. There's a number of linked issues to poor performance of ref.func and while this isn't a truly "zero cost" implementation it is significantly faster than it otherwise is today. The same implementation as before, where the fields are unconditionally initialized, is used no matter what. Conditional initialization could be part of a later runtime refactoring, if needed.

Note: this is a draft PR since there's an open design question around the Cranelift side of things I'd like to discuss this coming Wednesday.

alexcrichton · 2026-10-19T22:23:14Z

+;; @001e                               v3 = load.i64 user16 aligned readonly region2 v2+8
+;; @001e                               v4 = load.i64 notrap aligned readonly region3 v2+24
+;; @001e                               call_indirect sig0, v3(v4, v0)
+;; @0022                               v5 = load.i64 user16 aligned readonly region2 v2+8
+;; @0022                               v6 = load.i64 notrap aligned readonly region3 v2+24
+;; @0022                               call_indirect sig0, v5(v6, v0)


I've a thread on Zulip about why this isn't optimizing

fitzgen · 2026-10-20T23:22:55Z

+    // TODO: ideally this (and `can_move`) are something that alias analysis
+    // would infer itself rather than relying on the CLIF generator to provide
+    // such fine-grained information about loads/stores that can otherwise be
+    // inferred. For now though that's expected to be relatively complicated so
+    // this is intended to bring benefit in the meantime, although it requires
+    // all users of this to manually verify that the memory is indeed
+    // `readonly`-compatible.


I don't think this is something that can be inferred, because that would require determining whether a given function call writes to the location (or alias region) in question.

I think we may want to, in the limit of time, annotate signatures with the set of alias regions they use (and maybe, in the fullness of time, split that into observe vs mutate), but that is a bit separate from this TODO I think.

Do you think it's worth having this comment at all? I tried to capture some of the Cranelift meeting discussion in this, but you're right that actually removing the need for this would be a pretty ambitious project

Sorry for the delayed response. Yeah I think we can remove this comment now, especially given the other changes that have landed or are in-progress clarifying readonly and adding GVN of readonly loads.

fitzgen · 2026-10-20T23:24:29Z

+    /// 21-bit page offset for ADRP. The immediate is the signed difference
+    /// between the 4KiB page of the label and the 4KiB page of the ADRP
+    /// instruction, with high 19 bits in bits 23:5 and low 2 bits in bits
+    /// 30:29. Equivalent to the `R_AARCH64_ADR_PREL_PG_HI21` relocation.
+    AdrpPage21,
+    /// Low 12 bits of the label's address in the 12-bit immediate of an ADD
+    /// (immediate), bits 21:10. Equivalent to the `R_AARCH64_ADD_ABS_LO12_NC`
+    /// relocation. This has the same 4KiB-alignment requirement as
+    /// `AdrpPage21`, with which it is paired.
+    AddLo12,
 }


Can the new relocations be added in a separate PR, just to help split this up and make it easier to review?

Unfortunately the core change here can't land without this since otherwise tests on aarch64/riscv64 will fail. I can land the change for relocations separately, but then they're not tested until this lands. I split them out into separate commits for this PR, but if you'd like I can land them ahead of time on main

I think landing them without tests in a separate PR first would have been easier to review (since Github makes it hard to mark files read while reviewing commit by commit) but I think it is fine at this point.

In the last Cranelift meeting, we discussed the semantics of load merging and the various memory flags, such as `can_move`, `readonly`, and `notrap`, and which of these permits GVN'ing redundant loads together. We concluded that for a load marked only `readonly` (so, may trap and cannot move), it should still be safe to GVN that load against earlier identical loads that dominate it. THe current egraph mid-end does not do this. The GVN-of-side-effecting-but-idempotent ops is fundamentally gated by `is_mergeable_for_egraph`, and in that function, we previously excluded all loads and stores, with the rationale that (i) readonly + can-move + notrap loads are *truly* pure and will be handled by the ordinary egraph GVN mechanisms, and (ii) all lother loads and stores are subject to whatever our alias analysis does. These loads occupy a middle ground: they cannot float and rematerialize anywhere (as a pure op could), but alias analysis is also too weak to do useful things in many situations, e.g. when the GVN might occur across a callsite. We'd still like to reason about the fundamental implication of `readonly` on its own: once any load to the address *has* occurred (at an original location that hasn't been code-motioned, etc), and if we continue past that point (no trap), then `readonly` itself implies that the loaded value will never change -- so we can rewire subsequent identical loads to use the original value. This makes the sequence ``` v2 = load.i32 readonly v1 call fn0() v3 = load.i32 readonly v1 ``` properly GVN `v3` onto `v2`. Addresses the issue observed in bytecodealliance#14683 and discussed in [this Zulip thread](https://bytecodealliance.zulipchat.com/#narrow/channel/217117-cranelift/topic/.60VMFuncRef.60.20and.20.60.23.5Breadonly.5D.60/with/633147961).

…ance#14907) This is an API change for `MemFlags` to allow disabling flags in addition to disabling them. This came up during bytecodealliance#14683 as a possibly useful primitive to have, and subjectively I've found this sort of builder/setting configuration pretty flexible to use historically too.

Don't actually replace it with anything just yet, but get a whole bunch of `disas` tests blessed here to handle the updated renumbering of libcalls.

This commit moves the implementation of `ref.func` from a libcall to entirely within wasm code. The goal here is to optimize `ref.func` by primarily avoiding costly lookups of function pointers at runtime what's otherwise known statically at compile time. Specifically one of the main costs of `ref.func` is dynamically looking up a function's wasm/array pointers from its `FuncIndex`, but this is statically known at compile time. All data structures are already visible to wasm code (part of the `VMContext`) so no architectural changes were needed, it's instead just moving initialization into compiled code. This does mean that this now duplicates runtime code as well since that cannot be removed, but it's at least noted in both places that these are duplicates of each other. The net result of this is that `ref.func` executes much more quickly than before since `ref.func` is just a handful of loads/stores compared to a full call into the host. The primary motivator here, bytecodealliance#14616, means that initialization of element segments on imported tables, for example, should get much faster. Closes bytecodealliance#8212 Closes bytecodealliance#13295 Closes bytecodealliance#14616

Add a few more relocations to be handled with `LabelUse` and such.

A near `func_addr` on RISC-V 64 is an `auipc` with a `R_RISCV_PCREL_HI20` relocation against the target followed by an `addi` with a `R_RISCV_PCREL_LO12_I` relocation against the `auipc`. This maps both to the preexisting `LabelUse::PCRelHi20` and `LabelUse::PCRelLo12I` so `MachTextSectionBuilder` can resolve them within a text section, which is required for `ref.func` of a defined function on RISC-V 64. Wasmtime resolves the low half against the same target as the high half since `PCRelLo12I` is defined in terms of the final target.

fitzgen

Thanks!

…dealliance#14972) * Cranelift: merge readonly (but not notrap or can-move) loads. In the last Cranelift meeting, we discussed the semantics of load merging and the various memory flags, such as `can_move`, `readonly`, and `notrap`, and which of these permits GVN'ing redundant loads together. We concluded that for a load marked only `readonly` (so, may trap and cannot move), it should still be safe to GVN that load against earlier identical loads that dominate it. THe current egraph mid-end does not do this. The GVN-of-side-effecting-but-idempotent ops is fundamentally gated by `is_mergeable_for_egraph`, and in that function, we previously excluded all loads and stores, with the rationale that (i) readonly + can-move + notrap loads are *truly* pure and will be handled by the ordinary egraph GVN mechanisms, and (ii) all lother loads and stores are subject to whatever our alias analysis does. These loads occupy a middle ground: they cannot float and rematerialize anywhere (as a pure op could), but alias analysis is also too weak to do useful things in many situations, e.g. when the GVN might occur across a callsite. We'd still like to reason about the fundamental implication of `readonly` on its own: once any load to the address *has* occurred (at an original location that hasn't been code-motioned, etc), and if we continue past that point (no trap), then `readonly` itself implies that the loaded value will never change -- so we can rewire subsequent identical loads to use the original value. This makes the sequence ``` v2 = load.i32 readonly v1 call fn0() v3 = load.i32 readonly v1 ``` properly GVN `v3` onto `v2`. Addresses the issue observed in bytecodealliance#14683 and discussed in [this Zulip thread](https://bytecodealliance.zulipchat.com/#narrow/channel/217117-cranelift/topic/.60VMFuncRef.60.20and.20.60.23.5Breadonly.5D.60/with/633147961). * Review feedback. * Re-bless new test with better opts

alexcrichton mentioned this pull request Oct 12, 2026

Instantiation of modules with large element segments into imported tables regressed ~7x since #13487 #14616

Closed

github-actions Bot added cranelift Issues related to the Cranelift code generator cranelift:area:aarch64 Issues related to AArch64 backend. wasmtime:api Related to the API of the `wasmtime` crate itself labels Oct 12, 2026

alexcrichton force-pushed the optimize-ref-func branch from 27912b7 to 660281e Compare October 19, 2026 22:13

alexcrichton marked this pull request as ready for review October 19, 2026 22:22

alexcrichton requested review from a team as code owners October 19, 2026 22:22

alexcrichton requested review from cfallin and removed request for a team October 19, 2026 22:22

alexcrichton commented Oct 20, 2026

View reviewed changes

fitzgen reviewed Oct 20, 2026

View reviewed changes

alexcrichton mentioned this pull request Oct 21, 2026

Add a enabled: bool parameter to MemFlags modifiers #14907

Merged

cfallin mentioned this pull request Oct 23, 2026

Cranelift: merge readonly (but not notrap or can-move) loads. #14972

Merged

alexcrichton mentioned this pull request Oct 26, 2026

runtime: lazily initialize imported-table function references #14974

Open

alexcrichton added 8 commits October 26, 2026 07:50

Remove the ref_func libcall

c8dd5c9

Don't actually replace it with anything just yet, but get a whole bunch of `disas` tests blessed here to handle the updated renumbering of libcalls.

Fix tests on AArch64

1c7d35b

Add a few more relocations to be handled with `LabelUse` and such.

Fix CI

7f08045

Update the documentation of readonly

ee95856

Add a test for redundant VMFuncRef loads

932226a

Review comments

3a1c924

alexcrichton force-pushed the optimize-ref-func branch from 9a01889 to 3a1c924 Compare October 26, 2026 14:51

fitzgen approved these changes Oct 26, 2026

View reviewed changes

Review comments

4677e8b

alexcrichton enabled auto-merge October 26, 2026 22:36

alexcrichton added this pull request to the merge queue Oct 26, 2026

Merged via the queue into bytecodealliance:main with commit d27e208 Oct 26, 2026
61 checks passed

alexcrichton deleted the optimize-ref-func branch October 26, 2026 23:13

This was referenced Oct 27, 2026

Make WebAssembly ref.func instruction fast #8212

Closed

<Performance> fuzzbug: Repeated ref.func in a tiny hot loop is much slower in Wasmtime than in Wasmer Cranelift #13295

Closed

Navigation Menu

Repository navigation

Optimize the implementation of `ref.func` - #14683

Optimize the implementation of `ref.func`#14683
alexcrichton merged 9 commits into
bytecodealliance:mainfrom
alexcrichton:optimize-ref-func

alexcrichton commented Oct 12, 2026 •

edited

Loading

Uh oh!

alexcrichton Oct 19, 2026

Uh oh!

fitzgen Oct 20, 2026

Uh oh!

alexcrichton Oct 21, 2026

Uh oh!

fitzgen Oct 26, 2026

Uh oh!

fitzgen Oct 20, 2026

Uh oh!

alexcrichton Oct 21, 2026

Uh oh!

fitzgen Oct 26, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fitzgen left a comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

alexcrichton commented Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexcrichton Oct 19, 2026

Choose a reason for hiding this comment

Uh oh!

fitzgen Oct 20, 2026

Choose a reason for hiding this comment

Uh oh!

alexcrichton Oct 21, 2026

Choose a reason for hiding this comment

Uh oh!

fitzgen Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

fitzgen Oct 20, 2026

Choose a reason for hiding this comment

Uh oh!

alexcrichton Oct 21, 2026

Choose a reason for hiding this comment

Uh oh!

fitzgen Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fitzgen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

alexcrichton commented Oct 12, 2026 •

edited

Loading