[PATCH] D139010: [clang][WebAssembly] Implement support for table types and builtins

[Aaron Ballman via Phabricator via llvm-commits]

aaron.ballman added a comment.

In D139010#4159307 <https://reviews.llvm.org/D139010#4159307>, @tlively wrote:

> In D139010#4158540 <https://reviews.llvm.org/D139010#4158540>, @aaron.ballman wrote:
>
>> Roping in @jfb because I know he's been heavily involve in WebAssembly in the past and he may have ideas/opinions.
>>
>> High-level question: are externref, funcref, and table types all part of the WebAssembly standard, or are these extensions? (I wasn't aware that WebAssembly was a W3C standard or I'd have been asking this question much earlier -- sorry for that! I'm asking in regards to #4 in https://clang.llvm.org/get_involved.html#criteria)
>
> Yes, these features are all present in the WebAssembly standard: https://www.w3.org/TR/2022/WD-wasm-core-2-20220419/syntax/types.html#table-types

Thank you, that resolves any concerns I had about whether this met our usual extension criteria. I'm still uncomfortable with the type though because... it doesn't behave like anything else in the type system. I asked some questions on the test cases, and maybe knowing those answers will help me wrap my head around the design of the type.



================
Comment at: clang/test/SemaCXX/wasm-refs-and-tables.cpp:16-17
+__externref_t **t2;              // expected-error {{pointer to WebAssembly reference type is not allowed}}
+__externref_t ******t3;          // expected-error {{pointer to WebAssembly reference type is not allowed}}
+static __externref_t t4[3];      // expected-error {{only zero-length WebAssembly tables are currently supported}}
+static __externref_t t5[];       // expected-error {{only zero-length WebAssembly tables are currently supported}}
----------------
This seems really... confused. We can't form a pointer to the type, but we can form an array of the type (which decays into a pointer when you sneeze near it, and it's not clear whether that should be allowed or not) so long as it's a zero-length array (which is an extension in C and C++, so do we need to silence pedantic warnings in WASM for this?).


================
Comment at: clang/test/SemaCXX/wasm-refs-and-tables.cpp:88
+  varargs(1, table);              // expected-error {{cannot use WebAssembly table as a function parameter}}
+  table == 1;                     // expected-error {{invalid operands to binary expression ('__attribute__((address_space(1))) __externref_t[0]' and 'int')}}
+  1 >= table;                     // expected-error {{invalid operands to binary expression ('int' and '__attribute__((address_space(1))) __externref_t[0]')}}
----------------



================
Comment at: clang/test/SemaCXX/wasm-refs-and-tables.cpp:95
+  table ? : other_table;          // expected-error {{cannot use a WebAssembly table within a branch of a conditional expression}}
+  (void *)table;                  // expected-error {{cannot cast from a WebAssembly table}}
+  void *u;
----------------



================
Comment at: clang/test/SemaCXX/wasm-refs-and-tables.cpp:102
+
+  table[0];
+  table[0] = ref;
----------------
This involves array to pointer decay, so we're forming a pointer to the table here. Why is this pointer fine but others are not?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139010