On 6/25/25 8:58 PM, Andrew Pinski wrote:
In the case of tailing call with a return of a structure, currently
all large structures are rejected. We can allow the case were the return
of the "tail call" function is setting the return value of the current
function. This allows for the musttail that is located in pr71761-1.c.
This should be safe as sibcalls here is RSO is always set for this case so
the current function no longer owns the space.
There is a small fix needed for targets where targetm.calls.structure_value_rtx
returns non-null. The setting of this register was not being done for sibcalls
(pass == 0) but in this case we need to do that. Also adds a testcase which
shows the issue.
Bootstrapped and tested on x86_64-linux-gnu and aarch64-linux-gnu with no
regressions.
PR middle-end/71761
gcc/ChangeLog:
* calls.cc (can_implement_as_sibling_call_p): Don't reject
"structured" returns if the addr is the same as the current
result decl's memory.
(expand_call): For pass 0, also copy into struct_value_rtx
the correct value.
gcc/testsuite/ChangeLog:
* c-c++-common/pr71761-1.c: New test.
* gcc.dg/torture/tail-call-0.c: New test.
I'm uneasy about this, though I can certainly understand why we might
want to tackle this problem now vs 25 years ago when we originally
integrated that code.
My uneasiness isn't tied to a specific problem. Though we do have to
worry about PCC_STRUCT_RETURN, hidden parameters for struct return, how
to handle BLKmode objects that that need right vs left justification
and the fact that it may differ depending on if it's a MEM or REG object
(PA1.x SOM ABI IIRC). Does this interact with RVO? etc.
These may all be dealt with long before we get here, which would be
great. But it's far from obvious if that's the case or not.
jeff
