|
| 1 | +# Explicit tail calls & `loop_match` |
| 2 | + |
| 3 | +| Metadata | | |
| 4 | +| :-------------------- | ------------------------------------------------------------------------------------------------------ | |
| 5 | +| Point of contact | @folkertdev | |
| 6 | +| Status | Proposed | |
| 7 | +| Tracking issue | | |
| 8 | +| Other tracking issues | https://github.com/rust-lang/rust/issues/112788, https://github.com/rust-lang/rust/issues/132306 | |
| 9 | +| Zulip channel | | |
| 10 | +| [lang] champion | @scottmcm | |
| 11 | + |
| 12 | +## Summary |
| 13 | + |
| 14 | +It is important that rust generates efficient code. Guaranteed tail calls, `goto` and computed `goto` are techniques used in systems programming to squeeze out the last bit of performance. Rust should have these abilities. |
| 15 | + |
| 16 | +## Motivation |
| 17 | + |
| 18 | +### The status quo |
| 19 | + |
| 20 | +Both `explicit_tail_calls` and `loop_match` are unstable, and still require substantial work. |
| 21 | + |
| 22 | +### What we propose to do about it |
| 23 | + |
| 24 | +The LLVM 22 release improves tail call support on a number of platforms (specifically x86_64), unblocking work on `explicit_tail_calls` . We've also realized that there are new design issues around portability that need a solution. |
| 25 | + |
| 26 | +In light of these design issues, we'd also like to continue development of `loop_match`. This feature also solves the problem of providing good codegen for branchy code, but it is perfectly portable. |
| 27 | + |
| 28 | +### Work items over the next year |
| 29 | + |
| 30 | +| Task | Owner(s) | Notes | |
| 31 | +| ----------------------------------------------------------------------------------------------------------- | -------------------- | ---------------------------------------------------------------------------------------------------- | |
| 32 | +| add "computed goto" codegen to `loop_match` | @folkertdev, @WaffleLapkin | | |
| 33 | +| improve the `loop_match` implementation in `rustc_codegen_ssa` | @folkertdev, @WaffleLapkin | - https://github.com/rust-lang/rust/issues/143806 | |
| 34 | +| implement tail calls that pass arguments via the stack across targets (this may involve some work in LLVM) | @folkertdev, @WaffleLapkin | - https://github.com/rust-lang/rust/pull/151143<br>- https://github.com/rust-lang/rust/issues/148748 | |
| 35 | +| validate tail calls on HIR instead of THIR | @WaffleLapkin | | |
| 36 | +| accept tail call signatures that are a subtype | @WaffleLapkin | - https://github.com/rust-lang/rust/issues/144953 | |
| 37 | +| add experimental `extern "tail"` ABI that lowers to LLVM `tailcc` and lifts the same-signature restriction (this will probably require some work in LLVM) | @WaffleLapkin, @folkertdev | | |
| 38 | + |
| 39 | +## Team asks |
| 40 | + |
| 41 | +| Team | Support level | Notes | |
| 42 | +| ---------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
| 43 | +| [compiler] | small | We expect to only need normal reviews. | |
| 44 | +| [lang] | Medium | Some architectures cannot support guaranteed tail calls. Our current list of limitations is:<br><br>- `wasm32`/`wasm64` need the `tail-call` target feature to be enabled<br>- `powerpc` (when `elf1` is used) cannot tail call functions in other objects<br><br>Hence, rust code using guaranteed tail calls is not as portable as standard rust code. We need T-lang feedback on how to resolve this.<br><br>The all-hands is well-timed to figure out a solution. | |
| 45 | + |
| 46 | +## Frequently asked questions |
| 47 | + |
| 48 | +### What do I do with this space? |
0 commit comments