Re: [PATCH] tailc: Improve tail recursion handling [PR119493]

2025-04-27 Thread Richard Biener
On Thu, 24 Apr 2025, Jakub Jelinek wrote: > On Tue, Apr 01, 2025 at 11:51:49AM +0200, Jakub Jelinek wrote: > > Here it is, ok if it passes bootstrap/regtest? I'll queue the interdiff > > between this patch and the previous one for GCC 16. > > Here is the interdiff to improve the tail recursion h

[PATCH] tailc: Improve tail recursion handling [PR119493]

2025-04-24 Thread Jakub Jelinek
On Tue, Apr 01, 2025 at 11:51:49AM +0200, Jakub Jelinek wrote: > Here it is, ok if it passes bootstrap/regtest? I'll queue the interdiff > between this patch and the previous one for GCC 16. Here is the interdiff to improve the tail recursion handling also for non-musttail calls. Bootstrapped/re

Re: [PATCH] tailc: Improve tail recursion handling [PR119493]

2025-04-01 Thread Jakub Jelinek
On Tue, Apr 01, 2025 at 10:46:15AM +0200, Richard Biener wrote: > This looks OK, but I wonder if ... > > - /* The parameter should be a real operand, so that phi node > > -created for it at the start of the function has the meaning > > -of copying the value. This te

Re: [PATCH] tailc: Improve tail recursion handling [PR119493]

2025-04-01 Thread Richard Biener
On Tue, 1 Apr 2025, Jakub Jelinek wrote: > Hi! > > This is a partial step towards fixing that PR. > For musttail recursive calls which have non-is_gimple_reg_type typed > parameters, the only case we've handled was if the exact parameter > was passed through (perhaps modified, but still the same

[PATCH] tailc: Improve tail recursion handling [PR119493]

2025-04-01 Thread Jakub Jelinek
Hi! This is a partial step towards fixing that PR. For musttail recursive calls which have non-is_gimple_reg_type typed parameters, the only case we've handled was if the exact parameter was passed through (perhaps modified, but still the same PARM_DECL). That isn't necessary, we can copy the argu