Hello, On Mon, 3 Jun 2024, Jakub Jelinek wrote:
> > 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. Yeah, but I think the way the current proposal is doing it is mostly equivalent and fine enough, as Andi mentioned (in my worry I haven't considered that overall the backward walk stops fairly soon and then only does something when a musttail is there). I still think that the tree pass being necessary for correctness is bad design, in the grand scheme of things, especially for those tests that are done for the call statement in isolation (i.e. tests about arguments like address-taken and suchlike, and return value, flags on the callee, and facts about the current function). Those should all move to calls.cc or cfgexpand IMHO. But I will yield on the discovery part that tree-tailcall is doing (i.e. those pieces that need to look at multiple statements, e.g. how the call result is used later); those are a bit harder to do in expand and how it's structured, and without getting rid of that part in tree-tailcall we have to run it at O0 anyway for musttail. And moving only parts of the tests to calls.cc doesn't seem so worthwhile to hold up the patch. So, I have no objections on the patch design anymore. Ciao, Michael.
