Re: [PATCH] PPC64 ABI conformance

[Alan Modra <amodra at bigpond dot net dot au>]

On Fri, Jan 16, 2004 at 02:33:53PM +0100, Hartmut Penner wrote:
> Hello,
>       current ppc64 compiler does not conform to the new 64bit ABI:
> Out of ABI document version 1.7:
> 
>   * If there is no known function prototype for a callee, or if the
>     function prototype for a callee contains an ellipsis and the
>     argument value is not part of the fixed arguments described by the
>     prototype, then floating point and vector values are passed according
>     to the following rules for non-floating, non-vector types.  In the
>     case of no known prototype this may result in two copies of floating
>     and vector argument values being passed.
[snip]
> @@ -3923,8 +3923,9 @@ function_arg_advance (CUMULATIVE_ARGS *c
> 
>        /* In variable-argument functions, vector arguments get GPRs allocated
>        even if they are going to be passed in a vector register.  */
> -      if (cum->stdarg && DEFAULT_ABI != ABI_V4)
> -     {
> +      if (DEFAULT_ABI != ABI_V4
> +          && (cum->stdarg || (TARGET_64BIT && !cum->prototype)))
> +        {
>         int align;
> 
>         /* Vector parameters must be 16-byte aligned.  This places

I don't think this will do as the PowerPC64 Linux ABI intends.  The
fixed args of a stdarg function call are supposed to be passed the same
way as args of an identical function without ellipsis.  So any place
that tests cum->stdarg in function_arg_advance should be viewed with
suspicion.  Also, vector args take space in the parameter save area
just as floating point args do.  The ABI gives this example for
a mix of floating point args and other arg types:

typedef struct {
  int    a;
  double dd;
} sparm;
sparm   s, t;
int     c, d, e;
long double ld;
double  ff, gg, hh;

x = func(c, ff, d, ld, s, gg, t, e, hh);

Parameter     Register     Offset in parameter save area
c             r3           0-7    (not stored in parameter save area)
ff            f1           8-15   (not stored)
d             r5           16-23  (not stored)
ld            f2,f3        24-39  (not stored)
s             r8,r9        40-55  (not stored)
gg            f4           56-63  (not stored)
t             (none)       64-79  (stored in parameter save area)
e             (none)       80-87  (stored)
hh            f5           88-95  (not stored)

This example assumes a prototype is in scope for "func".  Notice how r4,
r6 and r7 are not used to pass values.  f1, f2 and f3 in this instance
"shadow" them.  Vector args should do the same.  Thus a call to
"foo (vector int a, long b)" should pass a in v2 and b in r5.  A call
to "bar (long a, vector float b, long c)" would pass a in r3, b in v2,
and c in r7.

>From statements others have made, I believe this is different to the AIX
(and Darwin?) scheme, where vectors are passed as if they were specified
last in the argument list.

I think you want the following (but I'm not sure whether the original
test was correct for the other ABIs!):

      /* PowerPC64 Linux allocates GPRs for a vector argument even if
	 it is going to be passed in a vector register.  Darwin and
	 AIX do the same for variable-argument functions.  */
      if ((TARGET_ELF && TARGET_64BIT)
	  || (cum->stdarg && DEFAULT_ABI != ABI_V4))

[snip]
> Testcase ppc64-abi-2.c:

Could you please add a test here for a vector arg followed by integer
args?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre