[PATCH] D139871: [WebAssembly] Replace LOAD_SPLAT with SPLAT_VECTOR

[Thomas Lively via Phabricator via llvm-commits]

tlively added inline comments.


================
Comment at: llvm/test/CodeGen/WebAssembly/simd-load-splat.ll:8-14
 ; CHECK-LABEL: load_splat:
 ; CHECK-NEXT: .functype load_splat (i32, i32) -> (i32)
-; CHECK-NEXT: i32.load8_u $[[E:[0-9]+]]=, 0($0){{$}}
-; CHECK-NEXT: v128.load8_splat $push[[V:[0-9]+]]=, 0($0){{$}}
+; CHECK-NEXT: i32.load8_u $push[[E:[0-9]+]]=, 0($0){{$}}
+; CHECK-NEXT: local.tee $push[[T:[0-9]+]]=, $[[R:[0-9]+]]=, $pop[[E]]{{$}}
+; CHECK-NEXT: i8x16.splat $push[[V:[0-9]+]]=, $pop[[T]]{{$}}
 ; CHECK-NEXT: v128.store 0($1), $pop[[V]]{{$}}
+; CHECK-NEXT: return $[[R]]{{$}}
----------------
aheejin wrote:
> luke wrote:
> > luke wrote:
> > > This results in one more instruction, but one less load. The resulting binary code size is probably comparable since tee is usually only two bytes.
> > This seems to be triggered by some reordering LLVM does with `splat_vector`
> I think I was told that we prefer `load_splat` over `splat` from @tlively (correct me if I'm wrong), but not sure if it was for performance or code size reasons. We have a specific order of preference written as `if`-`else` chain in https://github.com/llvm/llvm-project/blob/8a55264be311bf54ddef0430c712ad51a80a5f7f/llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp#L1938-L2193; I wonder if this has any impact on that.
I think the rationale for preferring `load_splat` over `splat` there was simply because `load_splat` could do more work in a single instruction, so it's assumed to be faster than doing the same work in two instructions (but we don't have any experimental data on that). I think the change to this output is fine, since it actually does less work (assuming loads are more work than tees).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139871/new/

https://reviews.llvm.org/D139871