Repository navigation
Teach rustc to do tail calls #217
Description
Activity
Per Graydon, we need to do some more thinking about calling conventions before implementing this. LLVM requires the fastcc convention to implement tail calls, but it doesn't do quite what we want:
graydon: brson: judging from comments in llvm-land, we may be in trouble. we might be able to compensate for what fastcc is doing today, but it's allowed to change its mind tomorrow.
graydon: I thought fastcc == x86_fastcall, but I was wrong.
graydon: those are different calling conventions. fastcc is "whatever llvm feels like this week"
graydon: we need to switch to x86_fastcall and then, longer-term, write our own calling convention.This is currently half-implemented due to some complications in the way LLVM treats tail calls. Rustc parses 'be' expressions and translates them as call+ret pairs, which is enough to get us to 'working' on simple, not-very-deep cases. Might be enough to bootstrap.
There is apparently only one CC (fastcc) which supports guaranteed tail calls, and to adapt to it we need to change our ABI assumptions in several places (it turns into callee-restore when you enable the -tailcallopt flag). So even if we annotate our call+ret pairs with 'tail', as required, we can't actually tell LLVM to start performing that optimization yet.
Turned out not to need more implementation than is shown here for self-hosting. Punting to next milestone.
Anyone feel we're actually going to do this anymore?
Doesn't seem like it's going to happen.
What is the situation with LLVM and tail calls? If they can be made to reliably work without some invasive stuff like declaring the callee to be tail-called, we could define a limited set of things that can be passed to tail-calls (caller's own arguments, scalars), and error when something else is passed. Such tail calls might not be very useful in practice, though.
Is it possible that looking at Haskell's GHC LLVM-backend might be helpful?
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM
http://llvm.org/docs/LangRef.html#callingconv
http://llvm.org/docs/CodeGenerator.html#tailcalloptReacted by Ricardo Fernández SerrataThey only work with a callee ABI that is suboptimal in non-tail-call cases. So in a sense, yes, they require the callee to be declared-to-be-tail-called.
We could implement this by, say, analyzing a crate and when we find a function that is tail called, either separately compiling it under the friendly-to-tail-call ABI, or compiling wrappers that switch ABI on entry, or something. Or alternatively we can switch every function everywhere to using the tail-call-friendly ABI. I'm not sure if we're currently doing that. We were for a while but we may have stopped. It's the LLVM "fastcall" ABI, which I don't think we're using anymore.
In any case, it's a bit of a mess.
We have sibling call optimization, now. Are we planning to try to do more?
This continues to come up in conversation, and we've reserved
beagain. Reopening.3 remaining items
It's maybe worth noting that Haskell commonly needs a static argument transformation for inlining, fusion, etc. http://stackoverflow.com/a/9660027/667457
Rust could support the static argument transformation by saying that functions defined inside another function should be elidgible for tailcall optimizations. Or simply warn if tailcalls between functions nested inside another fuction failed sibling optimization. Not sure the current situation.
Reacted by Ricardo Fernández SerrataIt is sad the tail recursion will not be implemented. Then I have a question: why creating a language syntax that seems like a functional language syntax if there lacks an essential feature of functional?
Reacted by Gerald, soc, Agustin, Zhengxu Chen, Pierre Thierry, Jakub Molinski, Zelphir Kaltstahl, Steve Godin, Ethan, Bhavani Shankar and 3 moreReacted by Damian Poddebniak and Paweł ObrokReacted by Ricardo Fernández SerrataI'm news in rust and I'm very sad. I try a tail recursive function and I stack overflow so fast. worst when I compile in release the behavior change. He just don't call my function. A friend said to me that the LLVM optimize to undefined value (LLVM know that is a tail recursion infinite ?!?).
fn rec(i: i32) { rec(i + 1) } fn main() { println!("{}", rec(0)); }
I agree with Boiethios, a language with functional features who doesn't implement tail call miss something.
I write in C and C++, they don't guarantee tail call, but in fact they handle it very well. It's not gonna stop me to learn rust, now I know that rust doesn't handle it. I will code without so it's not a big problem.
But I think that is a very good feature for a modern language.
notice that
fn rec(i: i32) { println!("Hello"); rec(i + 1) }
stack overflow too in release mode of cargo
Reacted by Ricardo Fernández SerrataReacted by Hugo TrentesauxWe have plans to eventually implement guaranteed TCO, if possible. We even reserved a keyword for it, "become". Please check the RFCs repo.
On Aug 3, 2016, 19:46 -0400, Antoine PLASKOWSKI notifications@github.com, wrote:
I'm news in rust and I'm very sad. I try a tail recursive function and I stack overflow so fast. worst when I compile in release the behavior change. He just don't call my function. A friend said to me that the LLVM optimize to undefine value (LLVM know that is a tail recursion infinite ?!?).
fn rec(i: i32) { rec(i + 1) } fn main() { println!("{}", rec(0)); }
I'm agree with Boiethios, a language with functional features who doesn't implement tail call miss something.
I write in C and C++, they don't guaranty tail call but in fact they handle it very well. It's not gonna stop me to learn rust, now I know that rust doesn't handle it I will code without so it's not a big problem.
But I think that is a very good feature for a modern language.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (#217 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AABsipoedHrbnKDekmzCr-dl8M6g-Gojks5qcShKgaJpZM4AC-q_).Reacted by Don Rowe, Adelar da Silva Queiróz, Flux Xu, Gerald, sharils, Pablo Guerrero Rosel, Zhengxu Chen, Ruben Paz, Vladislav Zavialov, AJ Gardner and 16 moreReacted by seanjensengrey, Stargateur, Pablo de Oliveira Castro, horrorho, anonymous anonymous, Adelar da Silva Queiróz, Travis Kaufman, Gerald, Sander Maijers, Ruben Paz and 7 moreReacted by anonymous anonymous, Adelar da Silva Queiróz, Michael Garate, Pierre Thierry, Abhinav Sharma, Ethan, Philip Theus (prev. Mueller) and Felipe S. S. SchneiderJust a question: It is hypothetically possible to do call graph analysis and transform tail calls into loops, at least within a single crate, but it is computationally expensive at compile time and quite tricky to code. Was there any discussion of this possibility? That would still be an option now, without regard to the choice of calling convention.
Reacted by Brad Gibson- added a commit that references this issue
on Dec 12, 2017 lbstanza's approach is to require annotation of functions to make them eligible for TCO (defn+ instead of defn). In rust, that would largely mitigate the extra compile time overhead to timthelion's suggestion, just so long as you aren't using tail calls literally everywhere lol.
Reacted by Brandon Elam Barker- added a commit that references this issue
on Dec 9, 2021 - added a commit that references this issue
on Jun 4, 2024 - added a commit that references this issue
on Jan 3, 2025 - added a commit that references this issue
on Sep 8, 2025
Rustc doesn't know how to do tail calls ('be' rather than 'ret') yet. It shouldn't be too hard to teach it how.