wasmtime / PR #12826 [Cranelift] add type-aware imm64 con... · git-wasmtime

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:

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:

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.

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 than uN/iN one 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 in gen_isle.rs. (And stop generating the u64_*/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. For uN/iN, it was relatively straightforward to meta-generate operations because they were backed by Rust uN/iN built-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:

Wasmtime GitHub notifications bot (Apr 13 2026 at 10:33):

bongjunj updated PR #12826.

Wasmtime GitHub notifications bot (Apr 13 2026 at 10:36):

bongjunj updated PR #12826.

Wasmtime GitHub notifications bot (Apr 13 2026 at 11:19):

bongjunj updated PR #12826.

Wasmtime GitHub notifications bot (Apr 13 2026 at 11:35):

bongjunj updated PR #12826.

Wasmtime GitHub notifications bot (Apr 13 2026 at 11:35):

bongjunj commented on PR #12826:

Implemented imm64_* operations for constant foldings, and

updated constant folding rules to use the operations.

In addition, added a missing rule (-X) * C = X * (-C) using imm64_neg

Wasmtime GitHub notifications bot (Apr 13 2026 at 11:35):

bongjunj has marked PR #12826 as ready for review.

Wasmtime GitHub notifications bot (Apr 13 2026 at 15:06):

github-actions[bot] added the label isle on PR #12826.

Wasmtime GitHub notifications bot (Apr 13 2026 at 15:06):

github-actions[bot] commented on PR #12826:

Subscribe to Label Action

cc @cfallin, @fitzgen

<details>
This issue or pull request has been labeled: "cranelift", "isle"

Thus the following users have been cc'd because of the following labels:

cfallin: isle

fitzgen: isle

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>