Stream: git-wasmtime

Topic: wasmtime / PR #12232 s390x: Emit instructions for bitwise...

Wasmtime GitHub notifications bot (Dec 30 2025 at 15:49):

theotherjimmy opened PR #12232 from theotherjimmy:s390x-bitwise-fp to bytecodealliance:main:

cranelift requires that bitwise operations work across all data types, including floating point. The prior implementation of bitwise operations, xor in this example, would cause a panic
with the message:
no rule matched for term aluop_xor

This patch adds lowerings for bitwise operations on floating point registers using the vector instructions and the vector register overlay property of the s390x register file.

Partially addresses Issue #12197

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Dec 30 2025 at 15:49):

theotherjimmy requested alexcrichton for a review on PR #12232.

Wasmtime GitHub notifications bot (Dec 30 2025 at 15:49):

theotherjimmy requested wasmtime-compiler-reviewers for a review on PR #12232.

Wasmtime GitHub notifications bot (Dec 30 2025 at 22:06):

theotherjimmy edited PR #12232:

cranelift requires that bitwise operations work across all data types, including floating point. The prior implementation of bitwise operations, xor in this example, would cause a panic with the message:
no rule matched for term aluop_xor

This patch adds lowerings for bitwise operations on floating point registers using the vector instructions and the vector register overlay property of the s390x register file.

Partially addresses Issue #12197

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Jan 03 2026 at 01:34):

cfallin submitted PR review:

The lowerings here look reasonable but would you mind adding a runtest (or adding s390x to an existing runtest if one exists) as well, to verify?

Wasmtime GitHub notifications bot (Jan 06 2026 at 14:23):

theotherjimmy commented on PR #12232:

Yes. I'll make sure this is part of a runtest.

Wasmtime GitHub notifications bot (Jan 07 2026 at 16:11):

theotherjimmy commented on PR #12232:

So I added a simple test to bitops:

function %test_bnot_f32(f32) -> f32 fast {
block0(v0: f32):
    v2 = bnot v0
    return v2
}

; run: %test_bnot_f32(0x1.0) == -0x1.fffffep1

which causes pulley to panic:

    ; cargo run test ./filetests/filetests/runtests/bitops.clif
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
     Running `/home/jimbri01/src/rust/wasmtime/target/debug/clif-util test ./filetests/filetests/runtests/bitops.clif`

thread 'worker #1' (299483) panicked at cranelift/codegen/src/isa/pulley_shared/lower/isle.rs:207:22:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[2026-01-07T16:10:38Z ERROR cranelift_filetests::concurrent] FAIL: panicked in worker #1: called `Option::unwrap()` on a `None` value
FAIL ./filetests/filetests/runtests/bitops.clif: panicked in worker #1: called `Option::unwrap()` on a `None` value
1 tests
Error: 1 failure

So do I need to fix something in pulley to get this working?

Wasmtime GitHub notifications bot (Jan 07 2026 at 17:22):

alexcrichton commented on PR #12232:

I believe that's because Pulley doesn't implement bitwise fp ops, so you'll want to add a new *.clif runtest file which excludes pulley from the targets that are tested for that

Wasmtime GitHub notifications bot (Jan 07 2026 at 17:24):

theotherjimmy commented on PR #12232:

Is pulley missing these bitops something that we should track in Issue #12197 ?

Wasmtime GitHub notifications bot (Jan 07 2026 at 17:42):

theotherjimmy updated PR #12232.

Wasmtime GitHub notifications bot (Jan 07 2026 at 17:51):

theotherjimmy commented on PR #12232:

Looks like aarch64 has a problem with fp bitops as well.

Wasmtime GitHub notifications bot (Jan 07 2026 at 18:09):

theotherjimmy updated PR #12232.

Wasmtime GitHub notifications bot (Jan 07 2026 at 18:10):

theotherjimmy commented on PR #12232:

I removed aarch64 from the fp-bitops test. I'm thinking this should pass now.

Wasmtime GitHub notifications bot (Jan 07 2026 at 18:16):

alexcrichton commented on PR #12232:

Thanks! It's fine I think to leave Pulley out of that issue since it's a much more constrained backend than the others, but thanks for the consideration!

Wasmtime GitHub notifications bot (Jan 07 2026 at 18:16):

alexcrichton has enabled auto merge for PR #12232.

Wasmtime GitHub notifications bot (Jan 07 2026 at 18:55):

alexcrichton merged PR #12232.

Last updated: Jan 09 2026 at 13:15 UTC