[PATCH] D67784: [WebAssembly] vNxM.load_splat instructions

Thomas Lively via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 23 13:35:49 PDT 2019


tlively marked 3 inline comments as done.
tlively added inline comments.


================
Comment at: llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td:62
+  let mayLoad = 1, UseNamedOperandTable = 1,
+      Predicates = [HasUnimplementedSIMD128] in
+  defm LOAD_SPLAT_#vec :
----------------
aheejin wrote:
> I asked the same question in D67783, but why do we not need `SIMD128`? Other parts below too
HasUnimplementedSIMD128 implies HasSIMD128, so having both is redundant.


================
Comment at: llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td:75
+
+def wasm_load_splat_t : SDTypeProfile<1, 1, []>;
+def wasm_load_splat : SDNode<"WebAssemblyISD::LOAD_SPLAT", wasm_load_splat_t>;
----------------
aheejin wrote:
> Don't we need `SDTCisPtrTy<0>`?
No, the argument to `wasm_load_splat` is actually the result of the original load, so it is not necessarily an i32. It could also be an  i64, f32, or f64. The type checking of the pointer is handled by the `extloadi8`, `extloadi16`, and `load` nodes.


================
Comment at: llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td:78
+
+foreach args = [["v16i8", "i32", "extloadi8"], ["v8i16", "i32", "extloadi16"],
+                ["v4i32", "i32", "load"], ["v2i64", "i64", "load"],
----------------
aheejin wrote:
> Do we only do zero extension for splats?
We do undefined extension for splats, since the high bits are never observed. Only the original bits end up in the splatted vector.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67784





More information about the llvm-commits mailing list