Stream: git-wasmtime

Topic: wasmtime / issue #10996 aarch64 panic with `band` at opt_...

Wasmtime GitHub notifications bot (Jun 10 2025 at 13:19):

akldc opened issue #10996:

.clif Test Case

test optimize
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true

function %main() -> i64, f32 fast {

block0():
    v8 = iconst.i64 -3524126683585344751
    v10 = f32const 0x1.66e07ap-1
    v36 = band.f32 v10, v10
    return v8,v36
}

; print: %main()

When the opt_level is set to none, the result is as follows.

[x86    ] %main() -> [-3524126683585344751, 0x1.66e07ap-1]
[riscv64] %main() -> [-3524126683585344751, 0x1.66e07ap-1]
[aarch64] thread 'main' panicked at /home/obfuscator/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/regalloc2-0.12.2/src/ion/process.rs:1253:17:
Could not allocate minimal bundle, but the allocation problem should be possible to solve
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

But when opt_level is switched to speed:

[x86    ] %main() -> [-3524126683585344751, 0x1.66e07ap-1]
[riscv64] %main() -> [-3524126683585344751, 0x1.66e07ap-1]
[aarch64] %main() -> [-3524126683585344751, 0x1.66e07ap-1]

In this example, there's only one band instruction.
On aarch64, it throws an error before optimization but runs correctly after. What’s the reason for that?

Wasmtime GitHub notifications bot (Jun 10 2025 at 13:19):

akldc added the bug label to Issue #10996.

Wasmtime GitHub notifications bot (Jun 10 2025 at 13:19):

akldc added the cranelift label to Issue #10996.

Wasmtime GitHub notifications bot (Jun 10 2025 at 13:40):

bjorn3 commented on issue #10996:

The reason why it runs with optimizations is probably that the band gets optimized out, turning v36 into an alias to v10.

Wasmtime GitHub notifications bot (Jun 11 2025 at 13:26):

akldc commented on issue #10996:

@bjorn3
If the band operation on floating-point numbers is actually invalid or illegal, shouldn’t it cause an error both before and after optimization? Simply optimizing it away seems unsound, as it changes the program’s behavior rather than preserving its correctness.

Wasmtime GitHub notifications bot (Jun 11 2025 at 14:39):

alexcrichton added the cranelift:area:aarch64 label to Issue #10996.

Wasmtime GitHub notifications bot (Jun 11 2025 at 14:40):

alexcrichton commented on issue #10996:

Float-related bitops are legal, but generally not well supported across backends since they're so rarely used. We've concluded in the past we don't want to remove float-related bitops, so I think that this is a valid bug to have open personally.

The optimization here is sound in that if aarch64 generated code without panicking when optimizations are disabled then the code should do the same thing. The reason this passes with optimizations is as @bjorn3 said in that the shape of the IR being code-generated is different.

Wasmtime GitHub notifications bot (Jun 12 2025 at 14:03):

akldc commented on issue #10996:

@alexcrichton
Thank you for your response. I look forward to Cranelift becoming more sound over time.

Last updated: Dec 06 2025 at 06:05 UTC