Re: Patch to fix several compat failures on irix6.5

[Richard Sandiford <rsandifo at redhat dot com>]

Alan Modra <amodra@bigpond.net.au> writes:
> On Mon, Aug 25, 2003 at 02:00:33PM +0100, Richard Sandiford wrote:
> > *** calls.c	20 Aug 2003 21:46:48 -0000	1.293
> > --- calls.c	25 Aug 2003 08:28:02 -0000
> > *************** initialize_argument_information (int num
> > *** 1238,1243 ****
> > --- 1238,1251 ----
> >   #endif
> >   			     args[i].pass_on_stack ? 0 : args[i].partial,
> >   			     fndecl, args_size, &args[i].locate);
> > + #ifdef BLOCK_REG_PADDING
> > +       else
> > + 	/* The argument is passed entirely in registers.  See at which
> > + 	   end it should be padded.  */
> > + 	args[i].locate.where_pad =
> > + 	  BLOCK_REG_PADDING (mode, type,
> > + 			     int_size_in_bytes (type) <= UNITS_PER_WORD);
> > + #endif
> >   
> >         /* Update ARGS_SIZE, the total stack space for args so far.  */
> >   
> 
> Won't FUNCTION_ARG_PADDING do here?  That's what you get in
> locate_and_pad_parm.

FUNCTION_ARG_PADDING would be wrong for mips, see below.

> > ! #define BLOCK_REG_PADDING(MODE, TYPE, FIRST)		\
> > !   (mips_pad_reg_upward (MODE, TYPE) ? upward : downward)
> 
> Ignoring FIRST might cause a problem in emit_group_{load,store}.

You could well be right ;).  But what kind of problem are you referring to?
The docs for the macro say:

  Specify padding for the last element of a block move between registers and
  memory.  @var{first} is nonzero if this is the only element.

But for the MIPS ABIs, the size of the structure doesn't matter.
We'll pad a 9 byte structure in the same way as a 7 byte one.
Am I misunderstanding what FIRST does?

> > + /* Likewise BLOCK_REG_PADDING (MODE, TYPE, ...).  Return !BYTES_BIG_ENDIAN
> > +    if the least significant byte of the register has useful data.  Return
> > +    the opposite if the most significant byte does.  */
> > + 
> > + bool
> > + mips_pad_reg_upward (enum machine_mode mode, tree type)
> > + {
> > +   /* No shifting is required for floating-point arguments.  */
> > +   if (type != 0 ? FLOAT_TYPE_P (type) : GET_MODE_CLASS (mode) == MODE_FLOAT)
> > +     return !BYTES_BIG_ENDIAN;
> 
> Can the above be pushed into mips_pad_arg_upward?  I'm envisaging the
> day when BLOCK_REG_PADDING is defined for all targets in terms of
> FUNCTION_ARG_PADDING.

Well, with n32 & n64, floating point arguments are passed in the low part
of a floating point register:

        63          32 31           0
        +-------------+-------------+
        | XXXXXXXXXXX | float value | $fx
        +-------------+-------------+

whereas stack arguments are passed in the high part of a 64-bit stack slot:

        63          32 31           0
        +-------------+-------------+
        | float value | XXXXXXXXXXX | stack
        +-------------+-------------+

So the padding really is different here.  And that's why I need to use
BLOCK_REG_PADDING above, since we want the register padding rather than
the stack padding.

Richard