Re: [PATCH] Fix one-sized FP arrays returning on MIPS

[Eric Botcazou <ebotcazou at act-europe dot fr>]

> Hi Eric,

Hi Richard,

> Sorry for the late answer.  I was away last week, and I've been
> desperately trying to catch up on mail since.

My sympathy :-)

>> > - one-sized arrays of integers are returned in the upper half of $2,
>> > while they were returned in the lower half previously.  If I read
>> > correctly again, this ABI change is not listed in
>> > http://gcc.gnu.org/gcc-3.4/mips-abi.html.
>
> [...]
>
> And yes, IMO, we should treat these sorts of arrays as aggregates as well,
> in which case the definition of "aggregate" in mips-abi.html should be
> extended.  As Jim says, this case didn't occur to me, since it isn't a
> problem with C, C++ or (I believe) Fortran.

Agreed.

> > @@ -7331,6 +7332,12 @@ mips_fpr_return_fields (tree valtype, tr
> >    if (!TARGET_NEWABI)
> >      return 0;
> >
> > +  /* Accept one-sized arrays of FP type.  */
> > +  if (TREE_CODE (valtype) == ARRAY_TYPE
> > +      && TREE_CODE (TREE_TYPE (valtype)) == REAL_TYPE
> > +      && TYPE_MODE (valtype) != BLKmode)
> > +    return 1;
> > +
> >    if (TREE_CODE (valtype) != RECORD_TYPE)
> >      return 0;
>
> As far as I can tell, your patch treats arrays with one floating-point
> element in the same way as structures with one floating-point field,
> but it doesn't treat arrays with two elements in the same way as
> structures with two floating-point fields.  This seems a little
> inconsistent.

Maybe.  That's what GCC 3.2.x does though, and I didn't want to invent 
anything.  Now I can try to change it.

> I'm also suspicious of any ABI-related check that depends on TYPE_MODE
> rather than TYPE_CODE.

You just invented this macro, didn't you? :-)

> As I understand it, the special case for structures of one or two
> floating-point fields was motivated by Fortran complex values (the ABI
> having been defined before C had complex values too).  I don't see any
> particular reason to treat single-element floating-point arrays as a
> further special case: it seems better to treat all arrays alike.

Efficiency?  One-sized FP arrays generally live in FP regs both in the caller 
and the callee, and it would seem to be inefficient to copy them back and 
forth to general regs around the function return.

> In other words, I think the return_in_msb hook is right to return
> true for the test case you quote.

For integer one-sized arrays, FP one-sized arrays or both?

-- 
Eric Botcazou