Hi Segher,
On Fri, Oct 02, 2020 at 01:50:24PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 02, 2020 at 04:41:05PM +0930, Alan Modra wrote:
> > This moves an #ifdef block of code from calls.c to
> > targetm.function_ok_for_sibcall. Only two targets, x86 and rs6000,
> > define REG_PARM_STACK_SPACE or OUTGOING_REG_PARM_STACK_SPACE macros
> > that might vary depending on the called function. Macros like
> > UNITS_PER_WORD don't change over a function boundary, nor does the
> > MIPS ABI, nor does TARGET_64BIT on PA-RISC. Other targets are even
> > more trivially seen to not need the calls.c code.
> >
> > Besides cleaning up a small piece of #ifdef code, the motivation for
> > this patch is to allow tail calls on PowerPC for functions that
> > require less reg_parm_stack_space than their caller. The original
> > code in calls.c only permitted tail calls when exactly equal.
>
> > + /* If reg parm stack space increases, we cannot sibcall. */
> > + if (REG_PARM_STACK_SPACE (decl ? decl : fntype)
> > + > REG_PARM_STACK_SPACE (current_function_decl))
> > + {
> > + maybe_complain_about_tail_call (exp,
> > + "inconsistent size of stack space"
> > + " allocated for arguments which are"
> > + " passed in registers");
> > + return false;
> > + }
>
> Maybe change the message? You allow all sizes smaller or equal than
> the current size, "inconsistent" isn't very great for that.
We're talking about just two sizes here. For 64-bit ELFv2 the reg
parm save size is either 0 or 64 bytes. Yes, a better message would
be "caller lacks stack space allocated for aguments passed in
registers, required by callee".
Note that I'll likely be submitting a further patch that removes the
above code in rs6000-logue.c. I thought is safer to only make a small
change at the same time as moving code around.
The reasoning behind a followup patch is:
a) The generic code checks that arg passing space in the called
function is not greater than that in the current function, and,
b) ELFv2 only allocates reg_parm_stack_space when some parameter is
passed on the stack.
Point (b) means that zero reg_parm_stack_space implies zero stack
arg space, and non-zero reg_parm_stack_space implies non-zero stack
arg space. So the case of 0 reg_parm_stack_space in the caller and 64
in the callee will be caught by (a).
Also, there's a bug in the code I moved from calls.c. It should be
using INCOMING_REG_PARM_STACK_SPACE, to properly compare space known
to be allocated for the current function vs. space needed for the
called function. For an explanation of INCOMING_REG_PARM_STACK_SPACE
see https://gcc.gnu.org/pipermail/gcc-patches/2014-May/389867.html
Of course that bug doesn't matter in this context because it's always
been covered up by (a).
--
Alan Modra
Australia Development Lab, IBM
