[PATCH] calls.c:can_implement_as_sibling_call_p REG_PARM_STACK_SPACE check

[Segher Boessenkool]

Hi!

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.

> +static int __attribute__ ((__noclone__, __noinline__))
> +reg_args (int j1, int j2, int j3, int j4, int j5, int j6, int j7, int j8)
> +{
> +  return j1 + j2 + j3 + j4 + j5 + j6 + j7 + j8;
> +}
> +
> +int __attribute__ ((__noclone__, __noinline__))
> +stack_args (int j1, int j2, int j3, int j4, int j5, int j6, int j7, int j8,
> +	    int j9)
> +{
> +  if (j9 == 0)
> +    return 0;
> +  return reg_args (j1, j2, j3, j4, j5, j6, j7, j8);
> +}
> +
> +/* { dg-final { scan-assembler-not {(?n)^\s+bl\s} } } */

Nice testcase :-)  (You can do \M or even just a space instead of that
last \s, but this works fine.)

The rs6000 parts are fine (with the message improved perhaps).  Thanks!
The rest looks fine to me as well, fwiw.


Segher