On Fri, 2021-04-23 at 12:44 -0700, Josh Haberman via Gcc 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).
FWIW I implemented something like this in GCC's middle-end here: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9a385c2d3d74ffed78f2ed9ad47b844d2f294105 exposing it in API form for libgccjit: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=15c671a79ca66df5b1de70dd1a0b78414fe003ef https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#c.gcc_jit_rvalue_set_bool_require_tail_call but IIRC it's not yet exposed to the regular GCC frontends. Dave > > I wrote more about some motivation for guaranteed tail calls here: > > https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html > > 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
