Problem with intrinsic f32x4_convert_u32x4 in wasm

[vallsv]

Hi, i am playing around Wasm and SIMD, trying different implementation in different languages.

I dont know much Rust, but i have noticed a weird conversion with a test.

My Rust source code contains the following explicit intrinsic (and others):

use std::arch::wasm::f32x4_convert_u32x4;

...

let s1 = f32x4_convert_u32x4(...);

First of all, i really like that you have chosen f32x4_convert_u32x4 instead of f32x4_convert_i32x4_u, but it's detail.

Unfortunately It was not processing data as fast as i was expecting.
Checking the assembly with wasm2wat shows the following opcodes.

      i16x8.extract_lane_u 4
      f32.convert_i32_u
      f32x4.splat
      local.get 8
      i16x8.extract_lane_u 5
      f32.convert_i32_u
      f32x4.replace_lane 1
      local.get 8
      i16x8.extract_lane_u 6
      f32.convert_i32_u
      f32x4.replace_lane 2
      local.get 8
      i16x8.extract_lane_u 7
      f32.convert_i32_u
      f32x4.replace_lane 3

Other intrinsic like u32x4_extend_low_u16x8, u16x8_extend_low_u8x16 (and more), was properly converted.

Any idea where could come from the problem?

It maybe have something to do with

stdarch/crates/core_arch/src/wasm32/simd128.rs

Line 4159 in 4ae38a1

pub fn f32x4_convert_u32x4(a: v128) -> v128 {

, other use explicit llvm_ stuffs, but i have no idea how to check any changes anyway.

An equivalent algorithm written in AssemblyScript is generating the following opcode properly:

        f32x4.convert_i32x4_u

I can try to create a very small sample code, it you like.

I am using the following environment.

• wasm-pack version: 0.10.3
• rustc version: 1.63.0 (4b91a6ea7 2022-08-08)
• linux debian 10

[Amanieu]

cc @alexcrichton

[CryZe]

I don't seem to be able to reproduce this: https://rust.godbolt.org/z/K7z81T1nv

[vallsv]

Wow crazy tool.

Here is a way to reproduce the stuff https://rust.godbolt.org/z/zcY5vc4jP

Maybe the problem is more around u32x4_extend_low_u16x8?

    f32x4_convert_u32x4(u32x4_extend_low_u16x8(u16x8_extend_low_u8x16(x)))

[vallsv]

It's kind of weird. I have tested all of the combinations of this 3 intrinsic. Everything is working except one.

    f32x4_convert_i32x4(u32x4_extend_low_u16x8(x)) -> ko
    f32x4_convert_i32x4(u16x8_extend_low_u8x16(x)) -> ok
    f32x4_convert_i32x4(f32x4_convert_i32x4(x)) -> ok
    u32x4_extend_low_u16x8(u16x8_extend_low_u8x16(x)) -> ok
    u16x8_extend_low_u8x16(u32x4_extend_low_u16x8(x)) -> ok

[vallsv]

Oh, and btw

    f32x4_convert_u32x4(i32x4_extend_low_i16x8(x))   -> ok
    f32x4_convert_u32x4(u32x4_extend_low_u16x8(x)) -> ko

I can use the first one for my algorithm without any pbm :-)

[alexcrichton]

This looks like an LLVM issue, so I've opened llvm/llvm-project#57182 to track it.

[vallsv]

Unfortunately when i chain the 3 functions i am not able to have what i expect, anyway i use signed or unsigned types.

    f32x4_convert_u32x4(
        u32x4_extend_low_u16x8(
            u16x8_extend_low_u8x16(x)))

But in case it is a useful information, the following is converted with only intrinsic functions (but i can't do anything with the result).

    f32x4_convert_u32x4(
        u16x8_extend_low_u8x16(
            u32x4_extend_low_u16x8(x)))

[folkertdev]

The related LLVM issue has been resolved for 2.5 years, and the example code optimizes properly now.

[vallsv]

Very nice! Thanks a lot.