Stream: git-wasmtime

Topic: wasmtime / PR #14411 Add a same-`vmctx` analysis for core...

Wasmtime GitHub notifications bot (Sep 24 2026 at 19:45):

fitzgen opened PR #14411 from fitzgen:same-vmctx-analysis to bytecodealliance:main:

Depends on https://github.com/bytecodealliance/wasmtime/pull/14410

Function imports that always resolve to functions from the same instance hold
the same vmctx pointer in their VMFunctionImport slots. This analysis
identifies such function imports.

A future commit will leverage this information during Wasm-to-CLIF translation
so that they all load the callee vmctx from a single slot and let GVN collapse
what would otherwise be many identical loads into one.

Wasmtime GitHub notifications bot (Sep 24 2026 at 19:45):

fitzgen requested pchickey for a review on PR #14411.

Wasmtime GitHub notifications bot (Sep 24 2026 at 19:45):

fitzgen requested wasmtime-core-reviewers for a review on PR #14411.

Wasmtime GitHub notifications bot (Sep 24 2026 at 19:45):

fitzgen requested alexcrichton for a review on PR #14411.

Wasmtime GitHub notifications bot (Sep 24 2026 at 19:45):

fitzgen requested wasmtime-default-reviewers for a review on PR #14411.

Wasmtime GitHub notifications bot (Sep 24 2026 at 19:46):

pchickey unassigned pchickey from PR #14411 Add a same-vmctx analysis for core modules' function imports in components.

Wasmtime GitHub notifications bot (Sep 24 2026 at 21:01):

alexcrichton commented on PR #14411:

High-level question before diving in too deeply -- naively I'd expect this to be a fairly trivial analysis given known_imported_functions as an input -- if two functions are known to have the same import and that same import has the same vmctx then they can be linked together. This isn't currently using that field, though, but is doing similar-ish things in terms of tracking instantiations/arguments, following reexports, etc. Would it be possible to either intertwine these analyses or use the results from one in the other?

Wasmtime GitHub notifications bot (Sep 24 2026 at 21:06):

fitzgen commented on PR #14411:

The known imported functions is whether we are calling a particular function, regardless of which instance it is associated with. We could always call a particular function, but from different instances, which would make the rewrites based on the known-imported-functions analysis sound, but rewrites based on this one unsound; or we could also always get functions from a particular instance but different functions from that instance, which would be sound for the rewrites we do based on this analysis but unsound for the rewrites we do based on the known-imported-function analysis. We could have a always-same-instance-and-same-function analysis that keeps track of when an imported function is both always the same function and always the same instance, but this would miss optimization opportunities that each in isolation could provide.

The other thing we could do, without losing optimizations or soundness, is to fuse the traversals over the component DFG together, while keeping each analysis separate. I think that would be reasonable to do in a follow up, if we are concerned about the compile-time overheads involved here.

Wasmtime GitHub notifications bot (Sep 24 2026 at 21:16):

alexcrichton commented on PR #14411:

Aha that makes sense, I was mistakenly conflating function identity and instance identity (or something like that), so makes sense why these are different. Would it make sense to call out this sort of subtelty in the doc comments of the fields in ModuleTranslation? For example mentioning on known_imported_functions that an entry always represents the same function but that may come from different instantiations of the same instance, and on imported_func_vmctx_representative entries could be instantiated with different functions but they'd always be from the same instance.

I think that would be reasonable to do in a follow up

I was thinking mostly in terms of deduplication of code as opposed to speed or anything like that because much of the code felt familiar. Only worth following up if it makes sense to dedup a bit -- if things are actually pretty different no worries.

Wasmtime GitHub notifications bot (Sep 24 2026 at 21:30):

:thumbs_up: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Sep 24 2026 at 21:30):

:speech_balloon: alexcrichton created PR review comment:

Assuming it's possible to relatively easily refactor to do, this is one of the larger bits that might makes sense to share with the preexisting analyses.

Wasmtime GitHub notifications bot (Sep 24 2026 at 21:30):

:speech_balloon: alexcrichton created PR review comment:

Maybe prefix these with cache_* or scratch_* or similar to make it a bit more clear that they're just scratch spaces not actually holding anything useful that's persistent?

Wasmtime GitHub notifications bot (Sep 24 2026 at 21:30):

:speech_balloon: alexcrichton created PR review comment:

Would this maybe make more sense as an assert!?

Wasmtime GitHub notifications bot (Sep 25 2026 at 00:21):

:memo: fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Sep 25 2026 at 00:21):

:speech_balloon: fitzgen created PR review comment:

I'll do this in a follow up, it is a little more involved than I'd hoped.

Wasmtime GitHub notifications bot (Sep 25 2026 at 00:22):

fitzgen updated PR #14411.

Wasmtime GitHub notifications bot (Sep 25 2026 at 01:36):

fitzgen updated PR #14411.

Wasmtime GitHub notifications bot (Sep 25 2026 at 01:36):

fitzgen has enabled auto merge for PR #14411.

Wasmtime GitHub notifications bot (Sep 25 2026 at 01:45):

fitzgen added PR #14411 Add a same-vmctx analysis for core modules' function imports in components to the merge queue.

Wasmtime GitHub notifications bot (Sep 25 2026 at 02:12):

:check: fitzgen merged PR #14411.

Wasmtime GitHub notifications bot (Sep 25 2026 at 02:12):

fitzgen removed PR #14411 Add a same-vmctx analysis for core modules' function imports in components from the merge queue.

Last updated: Oct 11 2026 at 04:10 UTC