Stream: git-wasmtime

Topic: wasmtime / PR #13580 Cranelift: Remove the `stack_{load,s...

Wasmtime GitHub notifications bot (Jun 05 2026 at 23:00):

fitzgen opened PR #13580 from fitzgen:wasmtime-remove-stack-load-store to bytecodealliance:main:

These get immediately legalized to stack_addr and load or store, so frontends should just emit that pair directly. For convenience and backwards compat, we add InstBuilder::stack_load and InstBuilder::stack_store methods that emit the pair as a single operation. Unfortunately, these methods have to take an additional pointer-type parameter that the old version didn't have to take because the rewrite didn't happen until legalization time, so these new methods are not 100% backwards compatible. This also necessitated passing in a TargetFrontendConfig to FuncBuilder::finalize, which resulted in a bit of churn, but is fully mechanical.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Jun 05 2026 at 23:00):

fitzgen requested alexcrichton for a review on PR #13580.

Wasmtime GitHub notifications bot (Jun 05 2026 at 23:00):

fitzgen requested wasmtime-compiler-reviewers for a review on PR #13580.

Wasmtime GitHub notifications bot (Jun 05 2026 at 23:00):

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

Wasmtime GitHub notifications bot (Jun 05 2026 at 23:15):

:memo: alexcrichton submitted PR review:

Would it be possible to avoid changing finalize by looking at the stack slot's size field and choosing an appropriate type based on that?

Wasmtime GitHub notifications bot (Jun 06 2026 at 01:24):

github-actions[bot] added the label cranelift on PR #13580.

Wasmtime GitHub notifications bot (Jun 06 2026 at 01:24):

github-actions[bot] added the label cranelift:meta on PR #13580.

Wasmtime GitHub notifications bot (Jun 08 2026 at 16:10):

fitzgen commented on PR #13580:

Would it be possible to avoid changing finalize by looking at the stack slot's size field and choosing an appropriate type based on that?

Unfortunately not, because it isn't the stack slot's type that we need to pass in (that was already passed in) it is the size of the target pointer.

Wasmtime GitHub notifications bot (Jun 08 2026 at 17:06):

alexcrichton commented on PR #13580:

So, here, which I belive is the only need for changing finalize currently, the slot variable's size doesn't match the platform's pointer width?

Wasmtime GitHub notifications bot (Jun 08 2026 at 18:24):

fitzgen updated PR #13580.

Wasmtime GitHub notifications bot (Jun 08 2026 at 18:28):

fitzgen commented on PR #13580:

So, here, which I belive is the only need for changing finalize currently,

Correct, although I think it is very reasonable to require a target config when building CLIF in general (e.g. a small additional follow up refactor could make all the memcpy functions that want a target config as an argument stop taking that argument and using the same source of truth as finalize).

the slot variable's size doesn't match the platform's pointer width?

It does not match. For Wasmtime, for example, the slots are 4 bytes large (VMGcRef-sized) regardless of 64- or 32-bit target. In general, those slots are sized to the value that needs inclusion in stack maps, which can be of any arbitrary type.

Wasmtime GitHub notifications bot (Jun 08 2026 at 18:28):

fitzgen has enabled auto merge for PR #13580.

Wasmtime GitHub notifications bot (Jun 08 2026 at 18:35):

:thumbs_up: alexcrichton submitted PR review:

Ah right, indeed. Would it make sense to take in an entire &dyn TargetIsa here instead of just the TargetFrontendConfig? Or alternatively just take the pointer_type instead of TargetFrontendConfig?

Wasmtime GitHub notifications bot (Jun 08 2026 at 18:43):

fitzgen added PR #13580 Cranelift: Remove the stack_{load,store} instructions to the merge queue.

Wasmtime GitHub notifications bot (Jun 08 2026 at 18:55):

fitzgen commented on PR #13580:

Ah right, indeed. Would it make sense to take in an entire &dyn TargetIsa here instead of just the TargetFrontendConfig? Or alternatively just take the pointer_type instead of TargetFrontendConfig?

Other frontend methods (such as the memcpy stuff mentioned earlier) take TargetFrontendConfig so I was just trying to match that.

All we absolutely need is the pointer type but it feels a bit like overspecializing on the exact use case today, vs what feels "right" / fits with the design of the crate. &dyn TargetIsa is a bit more of a mid-end/backend thing, for example.

Wasmtime GitHub notifications bot (Jun 08 2026 at 19:08):

:check: fitzgen merged PR #13580.

Wasmtime GitHub notifications bot (Jun 08 2026 at 19:08):

fitzgen removed PR #13580 Cranelift: Remove the stack_{load,store} instructions from the merge queue.

Last updated: Jul 29 2026 at 05:03 UTC