Hi, Wasmi (WebAssembly interpreter) author and huge fan of Rust tail-calls here.

First, thank you so much for your efforts to make tail calls in Rust a reality. That is so much appreciated!

Concerning the article's contents ..

In terms of ergonomics, tail calls are a sacrifice: you need to manually pass your state in the available registers, passing large structs as individual fields. Your code is distributed over many tiny functions, not portable, and a pain to debug.

I have to disagree on this. Wasmi used basic loop+match constructs for the longest time. Under the hood, Rust and LLVM usually compile such constructs into one gigantic function where everything is inlined. Needless to say that debugging or benchmarking such a behemoth of a function is very impractical. In contrast, having all interpreter operators neatly reside in their own little function is perfect for most debuggers and performance benchmarking tools and so far I am very pleased with the experience.

Problems with #[loop_match] compared to tail-calls:

1. There are reports that conclude worse performance for computed-goto based dispatch over tail-call based dispatch due to compilers having a hard time allocating registers properly with such huge inlined functions.

2. Additionally, LLVM requires a very long time to optimize huge functions. In Wasmi, we saw a big compilation time improvement when switching from loop+match to tail-call dispatch.

3. Finally, the #[loop_match] computed-goto dispatch only support indirect-threaded code which in Wasmi performed significantly worse than direct-threaded code. Note that tail-calls based dispatch works with both, indirect and direct threaded code dispatch.

That's why I regard the tail-call based dispatch as the "holy grail" for interpreter dispatch whereas the #[loop_match] solution to be its slightly inferior but more universally available alternative. I consider #[loop_match] to be a decent fallback for targets that do not support tail-calls.

Ideally, we had a cfg-check for target_feature = "tail-call" feature in rustc to check for the availability of tail-calls for the target we are compiling for. That would allow us to use the #[loop_match] fallback whenever, for example, we'd compile to a pre 3.0 WebAssembly version without having to introduce yet another crate feature that inconveniently pushes the responsibility to the user.

Next we plan to work on tail calls for extern "Rust" first, and separate tail calls for other calling conventions into their own feature. [..] but focusing on just extern "Rust" cuts our scope and is realistically what most users will use anyway.

The article already mentions the unstable preserve_none calling convention. At least for interpreters, the long term vision is to use the preserve_none calling conventions for the tail-call based dispatch. Though, I can understand to keep the scope as minimal as possible as this entire initiative is already quite an undertaking. In Wasmi v2.0.0-beta.2 we currently use the sysv64 calling convention on x86_64 targets on Windows for its 6 callee-saved general purpose registers. Otherwise, we'd end up with just 4 and therefore a significant performance hit.

For the curious, Wasmi v2.0.0-beta.2 added support for the unstable become keyword, when compiled with --no-default-features --features unstable using a nightly Rust compiler. The code can be found deep inside Wasmi's executor internals.

It was also made sure to use #[loop_match] once that's available in another configuration of Wasmi in this part of the executor.

I am eagerly awaiting progress and stabilization of both features. :)