On Fri, Apr 23, 2021 at 2:45 PM Josh Haberman via Gcc <gcc@gcc.gnu.org> wrote: > > Would it be feasible to implement a "musttail" statement attribute in > GCC to get a guarantee that tail call optimization will be performed? > > Such an attribute has just landed in the trunk of Clang > (https://reviews.llvm.org/D99517). It makes it possible to write > algorithms that use arbitrarily long chains of tail calls without risk > of blowing the stack. I would love to see something like this land in > GCC also (ultimately I'd love to see it standardized). > > I wrote more about some motivation for guaranteed tail calls here: > https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html
So I was looking into the use case presented in that web page, it is the same reason why GCC has the computed gotos extension already. Is there a reason why you can't just use that instead? Thanks, Andrew Pinski > > GCC successfully optimizes tail calls in many cases already. What > would it take to provide an actual guarantee, and make it apply to > non-optimized builds also? > > The Clang implementation enforces several rules that must hold for the > attribute to be correct, including: > > - It must be on a function call that is tail position. > - Caller and callee must have compatible function signatures > (including the implicit "this", if any), differing only in cv > qualifiers. > - Caller and callee must use the same calling convention. > - Caller and callee may not be constructors or destructors. > - All arguments, the return type, and any temporaries created must be > trivially destructible. > - All variables currently in scope must be trivially destructible. > - The caller cannot be in a try block, an Objective-C block, or a > statement expression. > > Some of these restrictions may be overly strict for some calling > conventions, but they are useful as the "least common denominator" > that should be safe in all cases. When implementing this in Clang, we > found that we were able to reuse some of the checks around goto and > asm goto, since a tail call is sort of like a goto out of the > function's scope. > > Thanks, > Josh
