Wasmtime GitHub notifications bot (Mar 23 2026 at 13:40): 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.htmlPlease 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.rsHowever, 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 ofimm64_sdivas it requires the precise view of Cranelift constants to correctly perform "signedness"-aware computation. In addition, usingimm64-based constant operations, the implementation (writingsimplifyrules and more) is more straightforward and convenient since the primary representation of constants in Cranelift isimm64. (u64/i64are Rust representation of constant literals).This PR prepares such
imm64operations 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.htmlPlease 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.rsHowever, 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 ofimm64_sdivas it requires the precise view of Cranelift constants to correctly perform "signedness"-aware computation. In addition, usingimm64-based constant operations, the implementation (writingsimplifyrules and more) is more straightforward and convenient since the primary representation of constants in Cranelift isimm64. (u64/i64are Rust representation of constant literals).For these reasons, I'm proposing that we should prioritize
imm64-based approach rather thanuN/iNone to make it easier to develop safe constant folding operations. This PR prepares suchimm64operations 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.
Wasmtime GitHub notifications bot (Mar 23 2026 at 17:02):github-actions[bot] added the label cranelift on PR #12826.
Wasmtime GitHub notifications bot (Mar 24 2026 at 04:54):bongjunj updated PR #12826.
Wasmtime GitHub notifications bot (Mar 24 2026 at 15:19):fitzgen commented on PR #12826:
For these reasons, I'm proposing that we should prioritize
imm64-based approach rather thanuN/iNone to make it easier to develop safe constant folding operations.This makes sense to me.
I wonder if we can or should generate and/or enumerate these
imm64_*constructors ingen_isle.rs. (And stop generating theu64_*/i64_*versions?)
Wasmtime GitHub notifications bot (Mar 25 2026 at 00:40):bongjunj commented on PR #12826:
@fitzgen I think we should implement
imm64_*by hand rather than meta-generating them. ForuN/iN, it was relatively straightforward to meta-generate operations because they were backed by RustuN/iNbuilt-ins. However,imm64_*needs Cranelift specific semantics involving bitshifts/rotates/overflows; therefore, meta-generating them could make the implementation unnecessarily complex.
Wasmtime GitHub notifications bot (Mar 25 2026 at 15:40):fitzgen commented on PR #12826:
Makes sense to me :+1:
Last updated: Apr 12 2026 at 23:10 UTC