[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