On Tue, Apr 01, 2025 at 10:50:01AM +0200, Richard Biener wrote:
> > While working on the previous tailc patch, I've noticed the following
> > problem.
> > The testcase below fails, because we decide to tail recursion optimize
> > the call, but tail recursion (as documented in tree-tailcall.cc) needs to
> > add some result multiplication and/or addition if any tail recursion uses
> > accumulator, which is added right before the return.
> > So, if there are musttail non-recurive calls in the function, successful
> > tail recursion optimization will mean we'll later error on the musttail
> > calls. musttail recursive calls are ok, those would be tail recursion
> > optimized.
> >
> > So, the following patch punts on all tail recursion optimizations if it
> > needs accumulators (add and/or mult) if there is at least one non-recursive
> > musttail call.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> OK.
>
> Do we update cfun->has_musttail at some point for optimized away
> musttail calls with respect to inlining/DCE? I do wonder whether
I think we don't update it at all.
During inlining that is not a problem, because we clear musttail in functions
being inlined unless the call being inlined was musttail too and in that case
the caller should have cfun->has_musttail already.
And I think it isn't a big deal when it might be pessimistically set
even when the musttail calls are DCEd, in tree-tailcall.cc we can perform
some extra work if cfun->has_musttail is set, and in case of -O0/-Og even
that means running an entirely new pass, but it shouldn't be that expensive
and if we don't actually find any musttail calls, it behaves pretty much
the same as if cfun->has_musttail wasn't set (there are some cases where
with !cfun->has_musttail we punt earlier than with it, but if there are
no musttail calls, it shouldn't make a difference in the end except for
perhaps different details in -fdump-tree-tail{r,c}-details dump.
Jakub
