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. Ciao, Michael.
