pmatos added inline comments.
================
Comment at: clang/docs/LanguageExtensions.rst:2288
+argument is the index to which to store the value into, and the
+third argument is a value of reference type to store in the table.
+It returns nothing.
----------------
aaron.ballman wrote:
> This sounds like any reference type will work, e.g.,
> ```
> static __externref_t table[0];
> void func(int i) {
> int &ref = i;
> __builtin_wasm_table_set(table, i, ref);
> }
> ```
> so might want to say "value of ``_externref_t`` type" instead?
Any reference type will work, i.e. externref or funcref. You can also store
funcrefs in a wasm table. But of course, it needs to be well-typed. You cannot
store a funcref value in an externref table and vice-versa.
================
Comment at: clang/docs/LanguageExtensions.rst:2321
+This builtin function returns the size of the WebAssembly table.
+Takes as argument the table and returns an integer with the current
+table size.
----------------
aaron.ballman wrote:
> Returns an `int`? `size_t`? Something else?
Good point, should actually be size_t. Will change that and clarify in the
documentation.
================
Comment at: clang/docs/LanguageExtensions.rst:2340
+It takes three arguments. The first argument is the WebAssembly table
+to grow. The second argument is the reference typed value to store in
+the new table entries (the initialization value), and the third argument
----------------
aaron.ballman wrote:
> Same suggestion here as above regarding arbitrary reference types.
Same situation as above. These builtins can get any reference type, as long as
they match the table element type.
================
Comment at: clang/docs/LanguageExtensions.rst:2360-2361
+
+This builtin function sets all the entries of a WebAssembly table to a given
+reference typed value. It takes four arguments. The first argument is
+the WebAssembly table, the second argument is the index that starts the
----------------
aaron.ballman wrote:
> Same suggestion here as above regarding arbitrary reference types.
Same as above.
================
Comment at: clang/docs/LanguageExtensions.rst:2364-2365
+range, the third argument is the value to set in the new entries, and
+the fourth and the last argument is the size of the range. It returns
+nothing.
+
----------------
aaron.ballman wrote:
> What happens if the range is invalid for the table size? e.g., the user never
> called `__builtin_wasm_table_grow` before calling `__builtin_wasm_table_fill`?
The host executing the WebAssembly instance will trap. This is part of the
WebAssembly spec.
================
Comment at: clang/docs/LanguageExtensions.rst:2385
+source index from there the copy starts, and the fifth and last argument
+is the number of elements to copy. It returns nothing.
+
----------------
aaron.ballman wrote:
> Similar question here as above -- what happens when the range given is
> invalid for either one or both of the table arguments?
Trap on the host.
================
Comment at: clang/test/SemaCXX/wasm-refs-and-tables.cpp:35
+task<__externref_t[]> g() {
+ co_return table;
+}
----------------
aaron.ballman wrote:
> pmatos wrote:
> > @aaron.ballman I tried and failed to create a good testcase for co_return.
> > However creating coroutines seems to be an stdlib thing which I am not sure
> > how to test here. Do you have any suggestions here?
> ```
> #include "Inputs/std-coroutine.h"
>
> using std::suspend_always;
>
> struct promise_table {
> __externref_t[] get_return_object();
> suspend_always initial_suspend();
> suspend_always final_suspend() noexcept;
> void return_value(__externref_t[]);
> void unhandled_exception();
> };
>
> template <typename... T>
> struct std::coroutine_traits<__externref_t[], T...> { using promise_type =
> promise_table; };
>
> static __externref_t table[0];
> __externref_t[] func() {
> co_return table; // Cannot return a WebAssembly table?
> }
> ```
> Perhaps something along these lines?
But you cannot write promise_table because a table cannot be an argument in
return_value. Also, you cannot return a table in get_return_object. Doesn't
this invalidate straight away the use of a table with co-routines?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D139010/new/
https://reviews.llvm.org/D139010
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
