Cranelift: Tracking Issue: Missing ISLE lowering rules and internal panics

[abc767234318]

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)

  Click to view reproduction (.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

  Click to view reproduction (.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

  Click to view reproduction (.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)

  Click to view reproduction (.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)

  Click to view reproduction (.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
    }
  

[jgraef]

insertlane on i32x2 returns an error as well:

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

Click to view reproduction (.clif)

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
}

Edit: error occurs when compiling to x86_64

[theotherjimmy]

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?