gimple va_arg for mips

[Richard Sandiford]

Richard Henderson <rth@redhat.com> writes:
>> E.g., the following quote seems to suggest that pass-by-value
>> can still be used:
>
> Possibly, yes.  I don't know that calls.c actually handles this
> with variable sized arguments, but it might be possible.  Of
> course, that doesn't apply to the newabi...

Right.  But the bit I quoted seemed to imply that (at least in the
old days) you could pass MUST_PASS_IN_STACK arguments by value as
long as you pass them on the stack.  The quote seemed to be saying
"oh, and if you define REG_PARM_STACK_SPACE, any part of the argument
in the reg parm rea will be loaded into the appropriate registers".

In the case of newabi, we were supposed to pass MUST_PASS_IN_STACK
arguments in the normal stack area, by value.  And it seemed to work.

So I'm still a little confused.  Are you saying that this was never
actually supported, but happened to work?  Or is it something that
used to be supported but isn't any more?

>> > In addition, there appears to have been an alignment and padding problem
>> > with the old code.  It didn't follow the same padding as the caller side.
>> > See PAD_VARARGS_DOWN.
>> 
>> Sorry to be clueless, but I don't see what you mean.  Is the mips
>> definition of PAD_VARARGS_DOWN wrong?  Or do you mean that the old
>> code wasn't honouring it?
>
> I mean that FUNCTION_ARG_PADDING computes some padding, up or down,
> but the old code !EABI va_arg code always used pad up.  At least it
> looked that way to me.

The down padding was supposed to be handled by:

          ...
	  if (BYTES_BIG_ENDIAN)
	    addr_rtx = plus_constant (addr_rtx, rsize - size);
          ...

for !EABI_FLOAT_VARARGS_P and:

          ...
	  if (BYTES_BIG_ENDIAN && osize > size)
	    t = build (PLUS_EXPR, TREE_TYPE (t), t,
		       build_int_2 (osize - size, 0));
          ...

for EABI_FLOAT_VARARGS_P.

Richard