[WebAssembly] manual splat not recognized

[folkertdev]

The wasm backend does not recognize a manual splat, while other backends do. For e.g. s390x vectors are not part of the baseline, and the pattern is only recognized when the vector target feature is enabled. For wasm, enabling +simd128 still does not recognize the splat.

https://llvm.godbolt.org/z/z3Ma9fTja

For instance this IR

define dso_local void @foo(i16 noundef %v, ptr noalias noundef writeonly align 1 captures(none) dereferenceable(16) initializes((0, 16)) %p) unnamed_addr #0 {
start:
  store i16 %v, ptr %p, align 1
  %_5.sroa.4.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 2
  store i16 %v, ptr %_5.sroa.4.0.p.sroa_idx, align 1
  %_5.sroa.5.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 4
  store i16 %v, ptr %_5.sroa.5.0.p.sroa_idx, align 1
  %_5.sroa.6.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 6
  store i16 %v, ptr %_5.sroa.6.0.p.sroa_idx, align 1
  %_5.sroa.7.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 8
  store i16 %v, ptr %_5.sroa.7.0.p.sroa_idx, align 1
  %_5.sroa.8.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 10
  store i16 %v, ptr %_5.sroa.8.0.p.sroa_idx, align 1
  %_5.sroa.9.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 12
  store i16 %v, ptr %_5.sroa.9.0.p.sroa_idx, align 1
  %_5.sroa.10.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 14
  store i16 %v, ptr %_5.sroa.10.0.p.sroa_idx, align 1
  ret void
}

should optimize to

define dso_local void @foo(i16 noundef %v, ptr noalias noundef writeonly align 1 captures(none) dereferenceable(16) initializes((0, 16)) %p) unnamed_addr #0 {
start:
  %0 = insertelement <8 x i16> poison, i16 %v, i64 0
  %1 = shufflevector <8 x i16> %0, <8 x i16> poison, <8 x i32> zeroinitializer
  store <8 x i16> %1, ptr %p, align 1
  ret void
}

LLVM does just that for most targets, but not on webassembly.

This manual splat pattern is not uncommon in rust when array expressions are used, see rust-lang/rust#97804. Previously other backends also did not optimize this pattern, that was tracked in #55994 but the issue was silently resolved.

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: Folkert de Vries (folkertdev)

Details

The wasm backend does not recognize a manual splat, while other backends do. For e.g. `s390x` vectors are not part of the baseline, and the pattern is only recognized when the `vector` target feature is enabled. For wasm, enabling `+simd128` still does not recognize the splat.

https://llvm.godbolt.org/z/z3Ma9fTja

For instance this IR

define dso_local void @<!-- -->foo(i16 noundef %v, ptr noalias noundef writeonly align 1 captures(none) dereferenceable(16) initializes((0, 16)) %p) unnamed_addr #<!-- -->0 {
start:
  store i16 %v, ptr %p, align 1
  %_5.sroa.4.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 2
  store i16 %v, ptr %_5.sroa.4.0.p.sroa_idx, align 1
  %_5.sroa.5.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 4
  store i16 %v, ptr %_5.sroa.5.0.p.sroa_idx, align 1
  %_5.sroa.6.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 6
  store i16 %v, ptr %_5.sroa.6.0.p.sroa_idx, align 1
  %_5.sroa.7.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 8
  store i16 %v, ptr %_5.sroa.7.0.p.sroa_idx, align 1
  %_5.sroa.8.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 10
  store i16 %v, ptr %_5.sroa.8.0.p.sroa_idx, align 1
  %_5.sroa.9.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 12
  store i16 %v, ptr %_5.sroa.9.0.p.sroa_idx, align 1
  %_5.sroa.10.0.p.sroa_idx = getelementptr inbounds nuw i8, ptr %p, i32 14
  store i16 %v, ptr %_5.sroa.10.0.p.sroa_idx, align 1
  ret void
}

should optimize to

define dso_local void @<!-- -->foo(i16 noundef %v, ptr noalias noundef writeonly align 1 captures(none) dereferenceable(16) initializes((0, 16)) %p) unnamed_addr #<!-- -->0 {
start:
  %0 = insertelement &lt;8 x i16&gt; poison, i16 %v, i64 0
  %1 = shufflevector &lt;8 x i16&gt; %0, &lt;8 x i16&gt; poison, &lt;8 x i32&gt; zeroinitializer
  store &lt;8 x i16&gt; %1, ptr %p, align 1
  ret void
}

LLVM does just that for most targets, but not on webassembly.

This manual splat pattern is not uncommon in rust when array expressions are used, see rust-lang/rust#97804. Previously other backends also did not optimize this pattern, that was tracked in #55994 but the issue was silently resolved.

[ParkHanbum]

Perhaps this could be handled in slp-vectorizer
https://llvm.godbolt.org/z/rzb5x5naG
I'll find out why this is not worked

[ParkHanbum]

Debug log for X86
V1 : <8 x i16> <i16 0, i16 poison, i16 poison, i16 poison, i16 poison, i16 poison, i16 poison, i16 poison>0, 0, 0, 0, 0, 0, 0, 0,
We Reach here Identity !!
CreateShuffleVector CreateShuffleVector isEmpty Identity We Enter getShuffleCost :
TTI getShuffleCost : enter X86TTIImpl::getShuffleCost
1

Debug log for WebAssembly
V1 : <8 x i16> <i16 0, i16 poison, i16 poison, i16 poison, i16 poison, i16 poison, i16 poison, i16 poison>0, 0, 0, 0, 0, 0, 0, 0,
We Reach here Identity !!
CreateShuffleVector CreateShuffleVector isEmpty Identity We Enter getShuffleCost :
TTI getShuffleCost : 9
Cost : 9

WebAssembly lacks TargetTransformInfoImpl, so the cost for the identify shuffle vector on a single vector is set to 9. Consequently, the necessary optimization is not being performed. My question is: Is there a reason WebAssembly does not implement TargetTransformInfoImpl?

@dschuff @aheejin

[folkertdev]

My guess by default is that no-one got around to it (yet).

Also there is https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/WebAssembly/WebAssemblyTargetTransformInfo.h so I assume you mean something more specific?

[ParkHanbum]

Yes, this seems to be happening because WebAssembley did not calculate ShuffleCost. Specifically, in this example, we found that the phrase '%1 = shufflevector <8 x i16>%0, <8 x i16> poison, <8 x i32> zeroinitializer' counts as a cost of 8. However, since this phrase is an identity shuffle vector on a single vector, it should be inexpensive. IMO

[badumbatish]

I can open a PR for this tmr, i have a local patch ready