Stream: git-wasmtime

Topic: wasmtime / issue #9671 Cranelift: the params type of `x86...


view this post on Zulip Wasmtime GitHub notifications bot (Nov 25 2024 at 08:28):

abc767234318 opened issue #9671:

I constructed a clif file.
multi_func155.zip
I used the following command to run it.

clif-util run -v multi_func155.clif

But I got the following error:

cases/multi_func155.clif: Compilation error: Unsupported feature: should be implemented in ISLE: inst = `v20 = x86_pmaddubsw v11, v11  ; v11 = const0, v11 = const0`, type = `Some(types::I16X8)`
1 file
Error: 1 failure

The definition of x86_pmaddubsw is as following:

/// An instruction with equivalent semantics to `pmaddubsw` on x86.
///
/// This instruction will take signed bytes from the first argument and
/// multiply them against unsigned bytes in the second argument. Adjacent
/// pairs are then added, with saturating, to a 16-bit value and are packed
/// into the result.
///
/// Inputs:
///
/// - x: A SIMD vector type consisting of 16 lanes of 8-bit integers
/// - y: A SIMD vector type consisting of 16 lanes of 8-bit integers
///
/// Outputs:
///
/// - a: A SIMD vector with exactly 8 lanes of 16-bit values
#[allow(non_snake_case)]
fn x86_pmaddubsw(self, x: ir::Value, y: ir::Value) -> Value {
    let (inst, dfg) = self.Binary(Opcode::X86Pmaddubsw, types::INVALID, x, y);
    dfg.first_result(inst)
}

And lower rule of x86_pmaddubsw is as following:

;; Rules for `x86_pmaddubsw` ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(rule (lower (has_type $I16X8 (x86_pmaddubsw x y)))
      (if-let true (use_ssse3))
      (x64_pmaddubsw y x))

view this post on Zulip Wasmtime GitHub notifications bot (Nov 25 2024 at 08:53):

cfallin commented on issue #9671:

You likely need to enable use_ssse3: as you've shown in the lowering rule, we only have a lowering if that instruction set extension is enabled.

I'm not sure if clif-util run has a way to set these options, but at least clif-util compile does, using --set use_ssse3=true.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 25 2024 at 09:02):

abc767234318 commented on issue #9671:

You likely need to enable use_ssse3: as you've shown in the lowering rule, we only have a lowering if that instruction set extension is enabled.

I'm not sure if clif-util run has a way to set these options, but at least clif-util compile does, using --set use_ssse3=true.

Are x and y of type I8x16 or i16x8? The definition and lowering rule above look different.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 25 2024 at 09:02):

abc767234318 edited issue #9671:

I constructed a clif file.
multi_func155.zip
I used the following command to run it.

clif-util run -v multi_func155.clif

But I got the following error:

cases/multi_func155.clif: Compilation error: Unsupported feature: should be implemented in ISLE: inst = `v20 = x86_pmaddubsw v11, v11  ; v11 = const0, v11 = const0`, type = `Some(types::I16X8)`
1 file
Error: 1 failure

The definition of x86_pmaddubsw is as following:

/// An instruction with equivalent semantics to `pmaddubsw` on x86.
///
/// This instruction will take signed bytes from the first argument and
/// multiply them against unsigned bytes in the second argument. Adjacent
/// pairs are then added, with saturating, to a 16-bit value and are packed
/// into the result.
///
/// Inputs:
///
/// - x: A SIMD vector type consisting of 16 lanes of 8-bit integers
/// - y: A SIMD vector type consisting of 16 lanes of 8-bit integers
///
/// Outputs:
///
/// - a: A SIMD vector with exactly 8 lanes of 16-bit values
#[allow(non_snake_case)]
fn x86_pmaddubsw(self, x: ir::Value, y: ir::Value) -> Value {
    let (inst, dfg) = self.Binary(Opcode::X86Pmaddubsw, types::INVALID, x, y);
    dfg.first_result(inst)
}

And lowering rule of x86_pmaddubsw is as following:

;; Rules for `x86_pmaddubsw` ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(rule (lower (has_type $I16X8 (x86_pmaddubsw x y)))
      (if-let true (use_ssse3))
      (x64_pmaddubsw y x))

view this post on Zulip Wasmtime GitHub notifications bot (Nov 25 2024 at 16:47):

cfallin commented on issue #9671:

The lowering rule is checking the return type of the operator. The operator accepts i8x16 and produces i16x8. The doc-comment and lowering rule look correct and consistent to me.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 26 2024 at 01:43):

abc767234318 closed issue #9671:

I constructed a clif file.
multi_func155.zip
I used the following command to run it.

clif-util run -v multi_func155.clif

But I got the following error:

cases/multi_func155.clif: Compilation error: Unsupported feature: should be implemented in ISLE: inst = `v20 = x86_pmaddubsw v11, v11  ; v11 = const0, v11 = const0`, type = `Some(types::I16X8)`
1 file
Error: 1 failure

The definition of x86_pmaddubsw is as following:

/// An instruction with equivalent semantics to `pmaddubsw` on x86.
///
/// This instruction will take signed bytes from the first argument and
/// multiply them against unsigned bytes in the second argument. Adjacent
/// pairs are then added, with saturating, to a 16-bit value and are packed
/// into the result.
///
/// Inputs:
///
/// - x: A SIMD vector type consisting of 16 lanes of 8-bit integers
/// - y: A SIMD vector type consisting of 16 lanes of 8-bit integers
///
/// Outputs:
///
/// - a: A SIMD vector with exactly 8 lanes of 16-bit values
#[allow(non_snake_case)]
fn x86_pmaddubsw(self, x: ir::Value, y: ir::Value) -> Value {
    let (inst, dfg) = self.Binary(Opcode::X86Pmaddubsw, types::INVALID, x, y);
    dfg.first_result(inst)
}

And lowering rule of x86_pmaddubsw is as following:

;; Rules for `x86_pmaddubsw` ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(rule (lower (has_type $I16X8 (x86_pmaddubsw x y)))
      (if-let true (use_ssse3))
      (x64_pmaddubsw y x))

view this post on Zulip Wasmtime GitHub notifications bot (Nov 26 2024 at 01:43):

abc767234318 commented on issue #9671:

The lowering rule is checking the return type of the operator. The operator accepts i8x16 and produces i16x8. The doc-comment and lowering rule look correct and consistent to me.

Thank you very much. I will close this issue.


Last updated: Dec 23 2024 at 12:05 UTC