Stream: git-wasmtime

Topic: wasmtime / issue #12503 Cranelift: Misoptimization with s...

Wasmtime GitHub notifications bot (Feb 03 2026 at 16:41):

bjorn3 opened issue #12503:

.clif Test Case

test compile
set opt_level=speed_and_size
set enable_verifier=1
target aarch64

function u0:1360(i8) -> i8 system_v {
block0(v0: i8):
    v1 = iconst.i64 0
    v2 = iconst.i64 1
    v3 = select v0, v1, v2
    v4 = icmp_imm eq v3, 1
    return v4
}

Expected Results

Compiles

Actual Results

function u0:1360(i8) -> i8 system_v {
block0(v0: i8):
    v1 = iconst.i64 0
    v6 = icmp eq v0, v1  ; v1 = 0
;   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
; error: inst6 (v6 = icmp.i8 eq v0, v1  ; v1 = 0): arg 1 (v1) has type i64, expected i8

    return v6
}

; 1 verifier error detected (see above). Compilation aborted.

Versions and Environment

Cranelift version or commit: 0.128 and up

Operating system: Any

Architecture: Likely any. Seen on arm64 and x86_64.

Extra Info

This breaks cg_clif when updating to 0.128.2.

Likely a regression from https://github.com/bytecodealliance/wasmtime/pull/12135, cc @jameshu15869

Wasmtime GitHub notifications bot (Feb 03 2026 at 16:41):

bjorn3 added the bug label to Issue #12503.

Wasmtime GitHub notifications bot (Feb 03 2026 at 16:41):

bjorn3 added the cranelift label to Issue #12503.

Wasmtime GitHub notifications bot (Feb 03 2026 at 16:43):

cfallin commented on issue #12503:

As additional info, bjorn3 checked with me before posting this to verify it shouldn't become a security-critical miscompilation. I believe it can't be a miscompile: the rules in #12135 use a wrong (too-wide) type for a constant zero value, which the verifier will catch if enabled, but even if disabled, using a 64-bit-wide 0 in place of an 8-bit-wide 0 in a register should not result in incorrect execution.

It's still an incorrect verifier error and should be patched -- will post a PR shortly.

Wasmtime GitHub notifications bot (Feb 03 2026 at 16:50):

cfallin commented on issue #12503:

(Also, separately, our GPR immediate generation always fills the entire register on all architectures as far as I am aware: so even if the types are incorrect in the other direction, the whole register will still be zeroed.)

Wasmtime GitHub notifications bot (Feb 03 2026 at 17:06):

jameshu15869 commented on issue #12503:

the rules in #12135 use a wrong (too-wide) type for a constant zero value

Sorry for the slip-up. Thank you for the catch + fix!

Wasmtime GitHub notifications bot (Feb 03 2026 at 17:39):

cfallin commented on issue #12503:

@jameshu15869 don't be sorry at all -- it happens from time to time and it's often very very hard to see weird interactions or corner cases ahead of time. Thanks for the optimizations regardless!

Wasmtime GitHub notifications bot (Feb 03 2026 at 18:48):

fitzgen closed issue #12503:

.clif Test Case

test compile
set opt_level=speed_and_size
set enable_verifier=1
target aarch64

function u0:1360(i8) -> i8 system_v {
block0(v0: i8):
    v1 = iconst.i64 0
    v2 = iconst.i64 1
    v3 = select v0, v1, v2
    v4 = icmp_imm eq v3, 1
    return v4
}

Expected Results

Compiles

Actual Results

function u0:1360(i8) -> i8 system_v {
block0(v0: i8):
    v1 = iconst.i64 0
    v6 = icmp eq v0, v1  ; v1 = 0
;   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
; error: inst6 (v6 = icmp.i8 eq v0, v1  ; v1 = 0): arg 1 (v1) has type i64, expected i8

    return v6
}

; 1 verifier error detected (see above). Compilation aborted.

Versions and Environment

Cranelift version or commit: 0.128 and up

Operating system: Any

Architecture: Likely any. Seen on arm64 and x86_64.

Extra Info

This breaks cg_clif when updating to 0.128.2.

Likely a regression from https://github.com/bytecodealliance/wasmtime/pull/12135, cc @jameshu15869

Last updated: Feb 24 2026 at 04:36 UTC