* Store the memory export name
When the memory export is defined in the WASM module,
store the name of the export so that it can be read by
the application.
This is necessary for implementing the JavaScript
`WebAssembly.Module.exports()` function.
* Store the memory import name
When the memory import is defined in the WASM module,
store the name of the import so that it can be read by
the application.
This is necessary for implementing the JavaScript
`WebAssembly.Module.imports()` function.
* Store the table0 export name
When the table export is defined in the WASM module,
store the name of the export so that it can be read by
the application.
This is necessary for implementing the JavaScript
`WebAssembly.Module.exports()` function.
If the compiler cannot analyze memcpy, it must expect that pointer arguments may be stored as static data and must live for recursive calls.
In such cases, op_Store and op_Load operations will not get tail-call optimized.
By enclosing the local variables in a block before the recursive call, the storage duration does not extend far enough, allowing for TCO.
With C++ enum classes, the size of an enum object can vary depending
on the compiler generation mechanism (choosing the most optimal storage size
to contain all the variants) or a user-defined storage type. In wasm we
can only send int32_t and int64_t. That means, the enums using this
integer width for storage must also work properly. At runtime this works
flawlessly, the functions in wasm can return these values safely and
they are even converted back on the C++ side to their enum
representations, thanks to the code in wasm3 which does a cast an
integer cast. But when it comes to generating the code for function
arguments, the defined data structure is not enough to generalize the
code to allow enum classes even if they are of a proper (allowed) width.
This commit changes the defined data structure to create a data
structure literal for wasm so that it allows enum classes as well as
already defined data types.
Since https://reviews.llvm.org/D81689, wasm-ld has started wrapping
all exported functions including "_start" with surrounding ctor/dtor
calls. The wrapper function "_start.command_export" is exposed as
"_start".
wasm3 searched the entry function by looking up names indiscriminately.
However, it sometimes found the internal "_start" function, so ctor/dtor
were not called. To pick up the wrapper "_start", this patch changes to
search export names at first.