Re: MIPS problem with structures/varargs

[Jim Wilson <wilson at cygnus dot com>]

There are known problems with both the old (o32) and new (n32/n64) ABIs.
I've discussed this a few times on various lists, but mostly this was so
long ago that I don't remember all of the details.

Using FUNCTION_ARG_PADDING is one of the proposed solutions, however it
does have some flaws of its own.  It isn't used everywhere where one might
expect.  It is usually (but not always) used for arguments on the stack.
It is usually (but not always?) not used for arguments in registers.  It
is also used to change the meaning of one other macro, MUST_PASS_IN_STACK,
which means that if you change FUNCTION_ARG_PADDING then you probably have
to redefine MUST_PASS_IN_STACK to avoid accidentally changing its value.
MUST_PASS_IN_STACK is probably wrong for most targets anyways.  Overall though,
changing FUNCTION_ARG_PADDING is probably an improvement, because there will
probably be fewer new bugs created than old bugs fixed.  It can be annoying to
suddenly get a different set of bugs though.

Long term, I think we should move away from the current model where we control
argument passing by using a hundred different macros that interact in hard
to understand ways.  We should instead be asking the back end where the
arguments go, and get back some structured info.  The use of PARALLELs
return values from FUNCTION_ARG is a step in this direction, and tends to
be a good way to solve problems of this sort.  However, the current info
is not complete.  There is no alignment info for partial register values for
instance.  Also, the code isn't as good as it could be, because use of a
PARALLEL requires taking the address of an argument, which can force it onto
the stack unnecessarily.

Jim