Stream: git-wasmtime

Topic: wasmtime / issue #1057 idea: "Multi-return" functions for...

Wasmtime GitHub notifications bot (Jul 02 2026 at 16:29):

fitzgen closed issue #1057:

From the paper "Multi-return Function Call" (http://www.ccs.neu.edu/home/shivers/papers/mrlc-jfp.pdf).
The basic idea from the perspective of compiled code is to include multiple return pointers in a stack frame so functions can return to different places.

Compared to Result<T,E>

This is denotationally the same as return a value of a Rust enum with 1 variant according to each of the return pointer slots, with fields according to the returned data associated with that slot (registers, spilled stack slots, etc). But with the naive enum calling convention of adding a tag field, the caller needs to branch on the tag field, even if the enum value was just created before the return so nothing is in principle unpredictable. In the common case of a function "rethrowing" a Err, (Err(e0) => ... return Err(e1) ... math arm), the native way results results on O(n) branches (one per stack frame) one each of the Err tags, while this way allows the error return pointer to point to disjoint control flow for the failure case, catching and rethrowing without additional branches, so the only 1 branch is the original failure condition.

Compared to unwinding

Success and failure control flow is implemented identically, avoiding significant effort on the part of compiler writers in maintaining a completely separate implementation concepts while optimizations can work with both, and don't get stuck on the success failure boundary. At run time, the lack of any DWARF-like interpreters reduces dependencies and simplifies things too.

In short, we have the asymptotic efficiency of unwinding with the implementation (compiler and run-time) efficiency of enum return.

---

I talked to @eddyb about this once and he said to talk to someone on #cranelift, but alas I am on IRC less these days and I forgot their nick. Opening this to make sure the idea isn't lost completely due to my negligence. Cheers.

Wasmtime GitHub notifications bot (Jul 02 2026 at 16:29):

fitzgen commented on issue #1057:

Old issue; potential for new ABIs exists but we should have more-focused proposals in new issues if anyone is actually volunteering to do the work and maintenance.

Wasmtime GitHub notifications bot (Jul 02 2026 at 16:47):

bjorn3 commented on issue #1057:

Now that we have try_call and get_exception_handler_address it should be possible to implement this as frontend without needing Cranelift changes. You can pass the result of get_exception_handler_address to a function call using try_call and then for returning do a return_call to a machine code stub that moves the arguments to the return registers and then does a return to the value that was returned from get_exception_handler_address. It might be nice to add a new Cranelift instruction to replace the tail call to the machine code stub for better portability and performance.

Last updated: Jul 29 2026 at 05:03 UTC