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. 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. -Andi
