GitHub (Feb 28 2020 at 23:25): GitHub (Feb 28 2020 at 23:25):alexcrichton transferred Issue #553:
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 theErrtags, 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.
Last updated: Nov 22 2024 at 16:03 UTC