Explicit tail calls & `loop_match`

[tomassedovic]

Metadata
Point of contact	@folkertdev
Team(s)	compiler, lang
Goal document	2026/tail-call-loop-match

Summary

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.

Tasks and status

---

Note: we have updated the body to match the 2026 goal. Your original text is preserved below.

Details

Metadata
Point of contact	@folkertdev
Team(s)	compiler, lang
Goal document	2026/tail-call-loop-match

Summary

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.

Tasks and status

[tomassedovic]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[folkertdev]

We've made some progress

• Do proper signature equality checking for tail calls rust#156007
• Fix an ICE observed with an explicit tail-call in a default trait method rust#145270

We've also discussed why/how to convert tail calls into a loop #t-compiler/mir-opts > turning `become` into a loop, though there is no clear conclusion yet on how to move forward.

[folkertdev]

Key developments:

• add extern "tail" calling convention rust#157016 adds extern "tail" which uses LLVM's tailcc. Lifting the same-signature restriction is future work
• we learned that guaranteed tail calls on s390x are inherently broken https://godbolt.org/z/Y3rMcKc7e

  Yes, this is the problematic case. As %r6 is callee-saved, but also an argument register, for a tail call sequence there would be no place to restore the original value of %r6.

• Experimental: using indirectbr (i.e. computed goto in rust) rust#157214 is an experimental implementation of computed goto. Results are a bit mixed, but so far probably not good enough to justify including them. I need to write a proper blog post about this.
• Some good LLVM 23 developments: riscv and loongarch support has re-landed, and a tailcc bug on x86 has been fixed.

Blockers:

We need to figure out the most promising way forward. Most likely this is the extern "tail" route because it is explicitly target-specific and hence sidesteps many of the design issues we run into with explicit_tail_calls.

Help wanted:

The `extern "tail" calling convention will have to be custom, because we can't support indirect stack arguments (they'd be overwritten by the call). With the same-signature restriction these arguments can be stored in the caller's caller, but when the signatures don't need to match this is no longer possible.

[folkertdev]

Key developments

With extern "tail", on LLVM 23, on x86 and x86_64, your signatures no longer need to match.

• Lift the same-signature restriction for extern "tail" rust#157983

Work in progress

Turns our extern "tail" on AArch64 does not handle byval (used for structs that don't fit in arguments)

• [AArch64] support byval arguments in tail calls llvm/llvm-project#206718

And doing things properly turns out to be complicated

• Do proper signature equality checking for tail calls rust#156007

Help wanted

Not at the moment