[Cranelift] add type-aware imm64 constant folding operations

[bongjunj]

This is a followup of #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.

[fitzgen]

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?)

[bongjunj]

@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.

[fitzgen]

Makes sense to me 👍