[PATCH] D139010: [clang][WebAssembly] Implement support for table types and builtins
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Mar 15 08:21:35 PDT 2023
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
More information about the cfe-commits
mailing list