aarch64 panic with `band` at opt_level=none but runs correctly after optimization

[akldc]

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

[bjorn3]

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

[akldc]

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

[alexcrichton]

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.

[akldc]

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