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 w
> > 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.
There are more checks in find_tail_calls. The logic is fairly spread
out. Some
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
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,
> 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 cal
On Tue, 21 May 2024, Andi Kleen wrote:
> - Give error messages for all causes of non sibling call generation
> - When giving error messages clear the musttail flag to avoid ICEs
> - Error out when tree-tailcall failed to mark a must-tail call
> sibcall. In this case it doesn't know the true reason