WebAssembly: Suboptimal "promotion" of wasm_f32x4_convert_i32x4 into f32x4.convert_i32x4_u

[zeux]

When wasm_f32x4_convert_i32x4 intrinsic gets its input from an instruction that clears top bits, the conversion gets compiled into i32x4_u instead of i32x4_s variant; for example:

v128_t plsno(v128_t x)
{
    // u32x4 here changes the convert instruction; it's a problem because u32->f32 is way slower on pre-AVX512 HW
    x = wasm_u32x4_shr(x, 1);
    return wasm_f32x4_convert_i32x4(x);
}

With -msimd128 -O2 compiles into

        local.get       0
        i32.const       1
        i32x4.shr_u
        f32x4.convert_i32x4_u
        end_function

This is a problem because on x64 hardware, convert_i32x4_u gets lowered into a long multi instruction sequence unless the browser implements AVX512 code path and the hardware supports it. Thus this needlessly slows down efficient SIMD kernels.

[zeux]

P.S. On the two particular kernels I'm hitting this issue on, the performance regresses from 3.5 / 7.8 GB/s with i32x4_s to 2.9 / 6.0 GB/s, using v8 and Zen 4 CPU. v8 uses the following SSE codepath for this https://github.com/v8/v8/blob/64db989ac8679599d268f6596c4ec1cdf45ccb84/src/compiler/backend/x64/code-generator-x64.cc#L4205-L4218

The kernels are not microbenchmarks, they are just well optimized. Unfortunately I don't have a good way to work around this short of using something like volatile which recovers ~half of lost performance but has a cost by itself, and strictly regresses performance on ARM where i32x4_u convert costs the same as i32x4_s.

[zeux]

Presumably a regression from #82404 (and followup #88299), fyi @goldsteinn

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: Arseny Kapoulkine (zeux)

When wasm_f32x4_convert_i32x4 intrinsic gets its input from an instruction that clears top bits, the conversion gets compiled into i32x4_u instead of i32x4_s variant; for example:

v128_t plsno(v128_t x)
{
    // u32x4 here changes the convert instruction; it's a problem because u32->f32 is way slower on pre-AVX512 HW
    x = wasm_u32x4_shr(x, 1);
    return wasm_f32x4_convert_i32x4(x);
}

With -msimd128 -O2 compiles into

        local.get       0
        i32.const       1
        i32x4.shr_u
        f32x4.convert_i32x4_u
        end_function

This is a problem because on x64 hardware, convert_i32x4_u gets lowered into a long multi instruction sequence unless the browser implements AVX512 code path and the hardware supports it. Thus this needlessly slows down efficient SIMD kernels.

[goldsteinn]

Something like #86694 is probably missing from wasm backend.

[goldsteinn]

I am no longer actively contributing and I probably won't be able to get to this. A wasm maintainer should be able to handle this.

[zeux]

Yeah I submitted a PR earlier today to fix this #149609