wasm2c: implement the tail-call proposal

[keithw]

This PR implements the tail-call proposal in wasm2c. (Will be needed to update the testsuite -- the exception-handling tests now use tail calls.)

The basic strategy is:

• If a function doesn't make any tail-calls, it's written unchanged.
• If a function does make a tail-call, it is written twice: once as the "normal" version, and once as the "tailcallee" version.
• The normal version has the usual signature, and the tailcallee version has the signature void fn(void **instance_ptr, void *tail_call_stack, wasm_rt_tailcallee_t *next)
• When a "tailcallee" function starts, it unpacks its params from the tail_call_stack argument, and when it returns, it packs its results back into the tail_call_stack
• If a "tailcallee" function returns via a return_call or return_call_indirect, it sets next to point to the new function and instance_ptr to point to its originating module instance. If it returns normally, it sets next to NULL.
• When a "normal" function does a return_call or return_call_indirect, it implements a trampoline: it allocates space for the tail_call_stack, calls the tailcallee version of function, and then loops forever until next is NULL.

To simplify the generated code:

• when tail-calling a function that's known not to make a tail-call itself, the generated code just does a normal call instead. This allows wasm2c to avoid generating a lot of extra "tailcallee" versions of functions that don't need them.
• when importing a function, a weak import is used to supply "default" tail-call behavior (converting it into a normal call). This allows the host to avoid having to implement a "tailcallee" version of every import (e.g. the spectest imports, WASI, etc.) just in case it gets tail-called.

[shravanrn]

(fwiw: I tried to write "have you considered __attribute__((musttail)) to directly enforce tail-call" here.. But it seems it is not suitable for the purpose as it is too restrictive llvm/llvm-project#54964 and anyway we still need "tailcalee" variant of the function to support importing.)

Interesting! Thanks for sharing this. @keithw would probably know more, but I'll also try to have a look to see if we can use to ensure that the C code being generated would be tail-called when compiled with gcc/clang

[sbc100]

lgtm % comments

[sbc100]

Is the wasm_ prefix the correct one to use here? Why not wasm_rt_?

[sbc100]

Looks strange mixing C and C++ comments directly next each other like this.. maybe its fine since the // static is more like the type hint?

[keithw]

Agreed that it's a little strange, but it matches the existing style (e.g. on CWriter::ExportName and CWriter::ModuleInstanceTypeName). We could maybe change all these together in a future PR?

[sbc100]

Would it be readable/maintainable to define a macro in the internal header rather than try to stamp out the if/else/endif here?

[keithw]

Done (or at least attempted -- doing the #pragma inside a #define was a little tricky but hopefully the CI passes on Windows).

[shravanrn]

(Still need to look at a part of c-writer)

[shravanrn]

Sorry, one more batch of comments. I finally managed to go through the whole PR this time. Biggest concern is one new source of UB here that we need to avoid.

I think I finally understand the strategy for tailcalls you have chosen and the codegen for this in the example files now makes sense to me. This is nice in that we won't need any C compiler attributes to force a tail-call, since we are doing it by hand in the tail_call_stack.

I can't say I understand 100% of the c-writer code, but it mostly made sense to me. With a little code-dedup and refactoring, I think this is nearly there.

[sbc100]

This version seems to completely ignore fallback.. how does that work?

[shravanrn]

i think the fallback is just an alternate way to implement weak symbols in MSVC. IIUC, they aren't used/needed in the non MSVC environments as weak symbols are available.

[sbc100]

I guess I don't understand how that fallback function is used on MSVC but a weak symbol is used otherwise. Do we also declare the fallback symbol only under MSVC?

[keithw]

Yeah, the "fallback" parameter is only used on MSVC.

On GCC/clang, the "weak import" is implemented by defining a stub version of the import under its real name, and marking it as a weak symbol so it will be overridden by the real import if it exists.

On MSVC, it's implemented by defining the stub version of the import under the "fallback" name, and then telling the linker to use the fallback as a substitute for the real import if the real import doesn't exist.

[keithw]

@sbc100 Did you want to weigh in again on this one? My thinking is that after we get this in, we can finally update the testsuite and possibly cut a new release.

[keithw]

Ok, merging now, and then let's try to get the testsuite updated, a release cut, and #2308 merged (not necessarily in that order).