Stream: git-wasmtime

Topic: wasmtime / issue #12197 Cranelift: Tracking Issue: Missin...

Wasmtime GitHub notifications bot (Dec 22 2025 at 07:00):

abc767234318 opened issue #12197:

As suggested in #12171 , I am aggregating the missing lowering rules and internal errors I've encountered into a single tracking issue. I will update this list as I discover more cases.

X86_64

• [ ] vany_ture with i8x16 args (Panic: no rule matched for term bitcast_gpr_to_xmm)
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> i8 fast {

  block0:
  v4 = iconst.i8 -29
  v23 = scalar_to_vector.i8x16 v4 ; v4 = -29
  v49 = vany_true v23
  return v49
  }

  ; print: %main()

• [ ] sadd_sat / usub_sat with i64x2 / i32x4 operands
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> i64x2 fast {
  const0 = 0x7fffffffffffffff04621ba7d10dbff0
  block0:
  v13 = vconst.i64x2 const0
  v21 = sadd_sat.i64x2 v13, v13
  return v21
  }

  ; print: %main()

• [ ] uunarrow with i64x2 operands
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> i32x4 {
  const0 = 0x7e2ac3193c260db87e307092f0285f4c
  block0:
  v0 = vconst.f64x2 const0
  v1 = fcvt_to_uint_sat.i64x2 v0
  v2= vconst.i64x2 [1 1]
  v3 = uunarrow v1, v2

    jump block1
  

  block1:
  return v3
  }

  ; print: %main()

aarch64

• [ ] band_not with f64 args (Panic: thread 'main' panicked at cranelift/codegen/src/isa/aarch64/inst/emit.rs:97:5: assertion ``left == right`` failed)
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> f64 fast {

  block0:
  v2 = f64const 0.0
  v5 = iconst.i32 -428912370
  v11 = f64const 0x1.fffffffffffffp1023
  v22 = iconst.i32 0
  v39 = band_not v11, v2 ; v11 = 0x1.fffffffffffffp1023, v2 = 0.0
  return v39
  }

  ; print: %main()

S390x

• [ ] bxor with f32 and f64 block args (Panic: no rule matched for term aluop_xor)
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> f64 fast {

  block0:
  v10 = f32const -0x1.fffffep127
  v11 = f64const 0x1.20365be59651ap996

    v21 = bxor v11, v11  ; v11 = 0x1.20365be59651ap996, v11 = 0x1.20365be59651ap996
    v65 = iconst.i32 0
    return  v21
  

  }

Wasmtime GitHub notifications bot (Dec 22 2025 at 07:00):

abc767234318 added the bug label to Issue #12197.

Wasmtime GitHub notifications bot (Dec 22 2025 at 07:00):

abc767234318 added the cranelift label to Issue #12197.

Wasmtime GitHub notifications bot (Dec 22 2025 at 16:27):

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

Wasmtime GitHub notifications bot (Dec 22 2025 at 16:27):

alexcrichton added the cranelift:area:x86 label to Issue #12197.

Wasmtime GitHub notifications bot (Dec 22 2025 at 16:27):

alexcrichton added the cranelift:area:s390x label to Issue #12197.

Wasmtime GitHub notifications bot (Dec 23 2025 at 16:29):

jgraef commented on issue #12197:

insertlane on i32x2 returns an error as well:

should be implemented in ISLE: inst = `v5 = insertlane.i32x2 v4, v3, 1`, type = `Some(types::I32X2)`

<details>
<summary>Click to view reproduction (.clif)</summary>

function %main() -> f32x4, i32x2 system_v {
    ss0 = explicit_slot 4, align = 4, key = 0
    ss1 = explicit_slot 4, align = 4, key = 1

block0:
    v0 = iconst.i32 1
    stack_store v0, ss0  ; v0 = 1
    v1 = iconst.i32 2
    stack_store v1, ss1  ; v1 = 2
    v2 = stack_load.i32 ss0
    v3 = stack_load.i32 ss1
    v4 = splat.i32x2 v2
    v5 = insertlane v4, v3, 1
    v6 = f32const 0.0
    v7 = splat.f32x4 v6  ; v6 = 0.0
    return v7, v5
}

</details>

Wasmtime GitHub notifications bot (Dec 23 2025 at 16:46):

jgraef edited a comment on issue #12197:

insertlane on i32x2 returns an error as well:

should be implemented in ISLE: inst = `v5 = insertlane.i32x2 v4, v3, 1`, type = `Some(types::I32X2)`

<details>
<summary>Click to view reproduction (.clif)</summary>

function %main() -> f32x4, i32x2 system_v {
    ss0 = explicit_slot 4, align = 4, key = 0
    ss1 = explicit_slot 4, align = 4, key = 1

block0:
    v0 = iconst.i32 1
    stack_store v0, ss0  ; v0 = 1
    v1 = iconst.i32 2
    stack_store v1, ss1  ; v1 = 2
    v2 = stack_load.i32 ss0
    v3 = stack_load.i32 ss1
    v4 = splat.i32x2 v2
    v5 = insertlane v4, v3, 1
    v6 = f32const 0.0
    v7 = splat.f32x4 v6  ; v6 = 0.0
    return v7, v5
}

</details>

Edit: error occurs when compiling to x86_64

Wasmtime GitHub notifications bot (Dec 23 2025 at 19:39):

theotherjimmy commented on issue #12197:

I'll handle the s390x panic. Thanks for the reproducer.

Wasmtime GitHub notifications bot (Dec 23 2025 at 20:01):

theotherjimmy edited a comment on issue #12197:

I'll handle the s390x panic. Thanks for the reproducer. I noticed that the reproducer actually does not use v10 at all, using v11 only

---

It looks like this affects all binary operations on floating point numbers. I was able to get almost the same failure with the following combinations:

• F64 & F64
• F32 xor F32
• F64 | F64
  I think this will be a bit more of a lift, since these operations require moving the floating point numbers into GPRs, then moving the result back.

Wasmtime GitHub notifications bot (Dec 23 2025 at 20:01):

theotherjimmy edited a comment on issue #12197:

I'll handle the s390x panic. Thanks for the reproducer. I noticed that the reproducer actually does not use v10 at all, using v11 only

---

It looks like this affects all binary operations on floating point numbers. I was able to get almost the same failure with the following combinations:

• F64 & F64
• F32 xor F32
• F64 | F64
• ! F64
  I think this will be a bit more of a lift, since these operations require moving the floating point numbers into GPRs, then moving the result back.

Wasmtime GitHub notifications bot (Dec 23 2025 at 20:01):

theotherjimmy edited a comment on issue #12197:

I'll handle the s390x panic. Thanks for the reproducer. I noticed that the reproducer actually does not use v10 at all, using v11 only

---

It looks like this affects all binary operations on floating point numbers. I was able to get almost the same failure with the following combinations:

• F64 & F64
• F32 xor F32
• F64 | F64
• ! F64

I think this will be a bit more of a lift, since these operations require moving the floating point numbers into GPRs, then moving the result back.

Wasmtime GitHub notifications bot (Dec 23 2025 at 20:04):

theotherjimmy edited a comment on issue #12197:

I'll handle the s390x panic. Thanks for the reproducer. I noticed that the reproducer actually does not use v10 at all, using v11 only

---

It looks like this affects all binary operations on floating point numbers. I was able to get almost the same failure with the following combinations:

• F64 & F64
• F32 xor F32
• F64 | F64
• ! F64

That implies that the following reproducer would be simpler:

function %bnot_f32() -> f32 fast {
block0:
  v10 = f32const -0x1.fffffep127
  v21 = bnot v10
  return  v21
}

I think this will be a bit more of a lift, since these operations require moving the floating point numbers into GPRs, then moving the result back.

Wasmtime GitHub notifications bot (Dec 23 2025 at 20:04):

theotherjimmy edited a comment on issue #12197:

I'll handle the s390x panic. Thanks for the reproducer. I noticed that the reproducer actually does not use v10 at all, using v11 only

---

It looks like this affects all binary operations on floating point numbers. I was able to get almost the same failure with the following combinations:

• F64 & F64
• F32 xor F32
• F64 | F64
• ! F64

That implies that the following reproducer would be simpler:

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

I think this will be a bit more of a lift, since these operations require moving the floating point numbers into GPRs, then moving the result back.

Wasmtime GitHub notifications bot (Dec 23 2025 at 20:11):

theotherjimmy edited a comment on issue #12197:

I'll handle the s390x panic. Thanks for the reproducer. I noticed that the reproducer actually does not use v10 at all, using v11 only

---

It looks like this affects all binary operations on floating point numbers. I was able to get almost the same failure with the following combinations:

• F64 & F64
• F32 xor F32
• F64 | F64
• ! F64

That implies that the following reproducer would be simpler:

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

I think this will be a bit more of a lift, since these operations require moving the floating point numbers into GPRs, then moving the result back. Alternatively, it's possible to use the lower 16 vector register aliases with vector bit operations to avoid the moves. Making use of the floating point-vector register overlay would require that the register allocator to understand that this happens. Is this the case?

Wasmtime GitHub notifications bot (Dec 27 2025 at 13:34):

abc767234318 edited issue #12197:

As suggested in #12171 , I am aggregating the missing lowering rules and internal errors I've encountered into a single tracking issue. I will update this list as I discover more cases.

X86_64

• [ ] vany_ture with i8x16 args (Panic: no rule matched for term bitcast_gpr_to_xmm)
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> i8 fast {

  block0:
  v4 = iconst.i8 -29
  v23 = scalar_to_vector.i8x16 v4 ; v4 = -29
  v49 = vany_true v23
  return v49
  }

  ; print: %main()

• [ ] sadd_sat / uadd_sat/usub_sat/ssub_sat with i64x2 / i32x4 operands
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> i64x2 fast {
  const0 = 0x7fffffffffffffff04621ba7d10dbff0
  block0:
  v13 = vconst.i64x2 const0
  v21 = sadd_sat.i64x2 v13, v13
  return v21
  }

  ; print: %main()

• [ ] uunarrow with i64x2 operands
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> i32x4 {
  const0 = 0x7e2ac3193c260db87e307092f0285f4c
  block0:
  v0 = vconst.f64x2 const0
  v1 = fcvt_to_uint_sat.i64x2 v0
  v2= vconst.i64x2 [1 1]
  v3 = uunarrow v1, v2

    jump block1
  

  block1:
  return v3
  }

  ; print: %main()

aarch64

• [ ] band_not with f64 args (Panic: thread 'main' panicked at cranelift/codegen/src/isa/aarch64/inst/emit.rs:97:5: assertion ``left == right`` failed)
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> f64 fast {

  block0:
  v2 = f64const 0.0
  v5 = iconst.i32 -428912370
  v11 = f64const 0x1.fffffffffffffp1023
  v22 = iconst.i32 0
  v39 = band_not v11, v2 ; v11 = 0x1.fffffffffffffp1023, v2 = 0.0
  return v39
  }

  ; print: %main()

S390x

• [ ] bxor with f32 and f64 block args (Panic: no rule matched for term aluop_xor)
  <details>
  <summary>Click to view reproduction (.clif)</summary>

  ```clif
  function %main() -> f64 fast {

  block0:
  v10 = f32const -0x1.fffffep127
  v11 = f64const 0x1.20365be59651ap996

    v21 = bxor v11, v11  ; v11 = 0x1.20365be59651ap996, v11 = 0x1.20365be59651ap996
    v65 = iconst.i32 0
    return  v21
  

  }

Wasmtime GitHub notifications bot (Jan 08 2026 at 13:16):

theotherjimmy commented on issue #12197:

s390x issue fixed in #12232 , can we remove the s390x tag? or is there something else needed?

Wasmtime GitHub notifications bot (Jan 08 2026 at 15:25):

alexcrichton removed the cranelift:area:s390x label from Issue #12197.

Last updated: Jan 09 2026 at 13:15 UTC