[PATCH] D101112: [WebAssembly] Finalize wasm_simd128.h intrinsics

[Thomas Lively via Phabricator via cfe-commits]

tlively added inline comments.


================
Comment at: clang/lib/Headers/wasm_simd128.h:171
+
+#define wasm_v128_load8_lane(__ptr, __vec, __i)                                \
+  ((v128_t)__builtin_wasm_load8_lane((signed char *)(__ptr), (__i8x16)(__vec), \
----------------
aheejin wrote:
> dschuff wrote:
> > out of curiosity, why are these macros, while all the rest (including ones that don't need declarations such as `wasm_i64x2_eq`) seem to be inline functions?
> I was also curious about this too.
The `i` parameter needs to be an integer constant, and I never figured out a way to enforce that for a function parameter. (But using a macro works because the codegen for the builtin functions can error out on non-constant arguments.)


================
Comment at: clang/lib/Headers/wasm_simd128.h:648
+static __inline__ bool __DEFAULT_FN_ATTRS wasm_v128_any_true(v128_t __a) {
+  return __builtin_wasm_any_true_i8x16((__i8x16)__a);
+}
----------------
aheejin wrote:
> Do we not rename the builtin to `v128` as well?
Yeah, I think it would be probably be more consistent to do so.


================
Comment at: clang/lib/Headers/wasm_simd128.h:1389
+
+// Old intrinsic names supported to ease transitioning to the stand names. Do
+// not use these; they will be removed in the near future.
----------------
aheejin wrote:
> 
Oops, thanks!


================
Comment at: clang/lib/Headers/wasm_simd128.h:1398
+
+#ifdef __DEPRECATED
+#define __DEPRECATED_WASM_MACRO(__name, __replacement)                         \
----------------
aheejin wrote:
> What does this macro do?
This macro is defined when -Wdeprecated is enabled, so it can be used to detect when warnings about deprecated things should be emitted.


================
Comment at: clang/lib/Headers/wasm_simd128.h:1547
+static __inline__ v128_t __DEPRECATED_FN_ATTRS("wasm_u16x8_extend_low_u8x16")
+wasm_i16x8_widen_low_u8x16(v128_t __a) {
+  return wasm_u16x8_extend_low_u8x16(__a);
----------------
aheejin wrote:
> The deprecated function name and the new intrinsic say `u`. Should this be `u` too? I haven't checked every single entry, but there seem to be multiple instances like this.
No, the old name had an `i` here (see the change on 1059). The convention is to use `u` and `i` to communicate unsignedness and signedness. Previously this name just had a `u` on the `u8x16` at the end, which was sufficient to communicate whether this was the `_u` or `_s` variant of the instruction. For the new names, I'm trying to communicate signedness of both the parameters and results, so the new name uses a `u` in both locations. In contrast, e.g. `wasm_u16x8_narrow_i32x4` remains unchanged because the inputs to narrowing operations are treated as signed even if the output is unsigned.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101112