On Mon, Jun 03, 2024 at 07:02:00PM +0200, Michael Matz wrote:
> Hello,
>
> On Fri, 31 May 2024, Andi Kleen wrote:
>
> > > I think the ultimate knowledge if a call can or cannot be implemented as
> > > tail-call lies within calls.cc/expand_call: It is inherently
> > > target and ABI specific how arguments and returns are layed out, how the
> > > stack frame is generated, if arguments are or aren't removed by callers
> > > or callees and so on; all of that being knowledge that tree-tailcall
> > > doesn't have and doesn't want to have. As such tree-tailcall should
> > > not be regarded as ultimate truth, and failures of tree-tailcall to
> > > recognize something as tail-callable shouldn't matter.
> >
> > It's not the ultimate truth, but some of the checks it does are not
> > duplicated at expand time nor the backend. So it's one necessary pre
> > condition with the current code base.
> >
> > Yes maybe the checks could be all moved, but that's a much larger
> > project.
>
> Hmm. I count six tests in about 25 lines of code in
> tree-tailcall.cc:suitable_for_tail_opt_p and suitable_for_tail_call_opt_p.
>
> Are you perhaps worrying about the sibcall discovery itself (i.e. much of
> find_tail_calls)? Why would that be needed for musttail? Is that
> attribute sometimes applied to calls that aren't in fact sibcall-able?
>
> One thing I'm worried about is the need for a new sibcall pass at O0 just
> for sibcall discovery. find_tail_calls isn't cheap, because it computes
> live local variables for the whole function, potentially being quadratic.
But the pass could be done only if there is at least one musttail call
in a function (remembered in some cfun flag). If people use that attribute,
guess they are willing to pay for it.
Jakub
