Re: [PATCH] MIPS: Add a GNU attribute for -mips32 -mfp64 objects

[Thiemo Seufer <ths at networkno dot de>]

Richard Sandiford wrote:
> Paul Koning <pkoning@equallogic.com> writes:
> >>>>>> "Richard" == Richard Sandiford <rsandifo@nildram.co.uk> writes:
> >
> >  Richard> I agree with Joseph here.  Although it's redundant to
> >  Richard> specify -mfp64 with -msoft-float, it isn't actively wrong.
> >  Richard> The options have traditionally been orthogonal.  I don't
> >  Richard> think the assembler should assume that -mfp64 implies
> >  Richard> -mhard-float.
> >
> > It seems strange, since -msoft-float means no float registers, while
> > -mfp64 says there are float registers and they are 64 bits wide.
> 
> Well, -mhard-float and -msoft-float are ABI options.  -mfp64 is
> an architectural configuration option, and only affects calling
> conventions when combined with -mhard-float.

But "-mhard-float -mfp64" constitutes a new ABI variant. This is
the case I want to cover. The "-msoft-float -mfp64" should stay
tagged as soft float object.

> It is perfectly
> possible to write code that conforms to the soft-float ABI while
> still using FPU instructions within a function.

I wonder how relevant this possibility is in practice. To me it
sounds too subtle to be of much use.

> (Strictly speaking,
> the use of FPU instructions is also part of the ABI.  But it isn't
> what this attribute specifies; this attribute is about the calling
> conventions.)
> The practical example of the difference is MIPS16.  -mhard-float
> -mips16 doesn't say "use the FPU from MIPS16 code"; you can't.
> It says instead that the hard-float ABI is in effect, and that
> we need to use special stubs to interface with non-MIPS16 code.

And, for completeness, we have "-mips32r2 -mips16 -mhard-float -mfp64",
which tells the compiler to generate different stubs than the ones
needed for the standard hard float.


Thiemo