On Sat, Jul 6, 2024 at 7:08 PM Andi Kleen <a...@linux.intel.com> wrote: > > On Fri, Jul 05, 2024 at 01:45:17PM +0200, Richard Biener wrote: > > On Sat, Jun 22, 2024 at 9:00 PM Andi Kleen <a...@linux.intel.com> wrote: > > > > > > Move the error reporting for caller attributes to be > > > after the tail call discovery, so that we can give proper > > > error messages tagged to the calls. > > > > Hmm. This all gets a bit awkward. I realize that early checking > > gets us less compile-time unnecessarily spent for searching for > > a tail call - but at least for the musttail case parsing constraints > > should put a practical limit on how far to look? > > All the top level checks are for obscure situations, so it's unlikely > that it makes much difference for compile time either way. > > > > > So what I wonder is whether it would be better to separate > > searching for a (musttail) candidate separate from validation? > > > > We could for example invoke find_tail_calls twice, once to > > find a musttail candidate (can there be multiple ones?) and once > > to validate and error? Would that make the delaying less awkward? > > There can be multiple musttails in a function, in theory > one for every return. > > I'm not sure I see the awkward part? (other than perhaps > the not-quite-natural accumulation of opt_tailcalls). There > are alots of checks before and after discovery. This just > moves them all to be after. > > If the top level checks were done based on a discovered > list you would need extra loops to walk the candidates > later and error. It wouldn't be any simpler at least.
Thanks for clarifying. > Overall the logic in this pass is rather convoluted and > could deserve some cleanups and separation of concerns. > e.g. it would be better to separate tail calls and tail > recursion. But I'm not trying to rewrite the pass here. Understood. For a v9, can you squash the tree-tailcall.cc changes please? Thanks, Richard. > -Andi
