Stream: git-wasmtime

Topic: wasmtime / PR #12826 [Cranelift] add type-aware imm64 con...

Wasmtime GitHub notifications bot (Mar 23 2026 at 13:40):

bongjunj opened PR #12826 from prosyslab:feat-imm64-const-folding to bytecodealliance:main:

<!--
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
-->

This is a followup of https://github.com/bytecodealliance/wasmtime/pull/12764

I'm adding rules that perform constant foldings. However, currently, Cranelift mainly uses u64/i64_* operations that are meta-generated by https://github.com/bytecodealliance/wasmtime/blob/main/cranelift/codegen/meta/src/gen_isle.rs

However, those u64/i64 operations are not aware bitwidth specified by type specifier (usually captured by ty) and signedness of a constant. Thus one cannot easily handle overflow, shift/rotation crossing bitwidth boundaries. Therefore, one has to carefully reason about the bitwidth boundary conditions, but can occasionally fail to write a correct rule. On the other hand, imm64-based constant operations perform computations considering those bitwidth-related semantics. This advantage is observed in the current implementation of imm64_sdiv as it requires the precise view of Cranelift constants to correctly perform "signedness"-aware computation. In addition, using imm64-based constant operations, the implementation (writing simplify rules and more) is more straightforward and convenient since the primary representation of constants in Cranelift is imm64. (u64/i64 are Rust representation of constant literals).

This PR prepares such imm64 operations for further inclusion of various constant expressions.

Wasmtime GitHub notifications bot (Mar 23 2026 at 13:40):

bongjunj requested wasmtime-compiler-reviewers for a review on PR #12826.

Wasmtime GitHub notifications bot (Mar 23 2026 at 13:40):

bongjunj requested fitzgen for a review on PR #12826.

Wasmtime GitHub notifications bot (Mar 23 2026 at 13:40):

bongjunj edited PR #12826:

<!--
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
-->

This is a followup of https://github.com/bytecodealliance/wasmtime/pull/12764

I'm adding rules that perform constant foldings. However, currently, Cranelift mainly uses u64/i64_* operations that are meta-generated by https://github.com/bytecodealliance/wasmtime/blob/main/cranelift/codegen/meta/src/gen_isle.rs

However, those u64/i64 operations are not aware bitwidth specified by type specifier (usually captured by ty) and signedness of a constant. Thus one cannot easily handle overflow, shift/rotation crossing bitwidth boundaries. Therefore, one has to carefully reason about the bitwidth boundary conditions, but can occasionally fail to write a correct rule. On the other hand, imm64-based constant operations perform computations considering those bitwidth-related semantics. This advantage is observed in the current implementation of imm64_sdiv as it requires the precise view of Cranelift constants to correctly perform "signedness"-aware computation. In addition, using imm64-based constant operations, the implementation (writing simplify rules and more) is more straightforward and convenient since the primary representation of constants in Cranelift is imm64. (u64/i64 are Rust representation of constant literals).

For these reasons, I'm proposing that we should prioritize imm64-based approach rather than uN/iN one to make it easier to develop safe constant folding operations. This PR prepares such imm64 operations for further inclusion of various constant expressions.

Wasmtime GitHub notifications bot (Mar 23 2026 at 14:04):

bongjunj converted PR #12826 [Cranelift] add type-aware imm64 constant folding operations to a draft.

Last updated: Mar 23 2026 at 16:19 UTC