Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking

[Richard Sandiford <rdsandiford at googlemail dot com>]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Richard Sandiford <rdsandiford@googlemail.com> writes:
>> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> > Are you're OK with automatically selecting fpxx if no -mfp option, no
>> > .module and no .gnu_attribute exists? Such code would currently end up
>> > as FP ABI Any even if FP code was present, I don't suppose anything
>> > would get worse if this existing behaviour simply continued though.
>> 
>> The -mfp setting is usually implied by the -mabi setting.  I don't think
>> we should change that.  Since this is a new mode, and since the fpxx
>> markup will be available from the start, everyone using fpxx should say
>> so explicitly.
>> 
>> E.g. maybe the rules should be:
>> 
>> (1) Any explicit .gnu_attribute 4 is always used, although we might
>>     give a diagnostic if it's incompatible with the module-level
>> setting.
>> 
>> (2) Otherwise, if the code does not use FP then the attribute is left
>>     at the default of 0.
>> 
>> (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module-
>> level
>>     setting.
>> 
>> (4) For compatibility, -mabi=32 continues to imply -mfp32.  fpxx mode
>> must
>>     be selected explicitly.
>> 
>> Which was supposed to be simple, but maybe isn't so much.
>
> This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe'
> FP code but let's see if we can do without it. Setjmp/longjmp are the
> only obvious candidates for using FP code in assembly files and these
> need to transition to fpxx.
>
> The glibc implementation of setjmp/longjmp is in C so the new defaults
> from the compiler will lead to this being fpxx as -mips32r2 will imply
> -mfpxx so that is OK, these modules will be tagged as fpxx.

Hmm, I don't think -mips32r2 should make any difference here.
You've specified it so that fpxx will work with MIPS II and above
and I'd prefer not to have an architecture option implicitly changing
the ABI.  (They sometimes did in the long-distant past but it just
led to confusion.)

I think instead we should have a configuration switch that allows
a particular -mfp option to be inserted alongside -mabi=32 if no explicit
-mfp is given.  This is how most --with options work.  Maybe
--with-fp-32={32|64|xx}?  Specific triples could set a default value if
they like.  E.g. the MTI, SDE and mipsisa* ones would probably want to
default to --with-32-fp=xx.  Triples aimed at MIPS IV and below would
stay as they are.  (MIPS IV is sometimes used with -mabi=32.)

--with-fp-32 isn't the greatest name but is at least consistent with
--with-arch-32 and -mabi=32.  Maybe --with-fp-32=64 is so weird
that breaking consistency is better though.

> Currently newlib's implementation is assembly code with no
> .gnu_attributes. Under the rules above this would start to be implicitly
> tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we transition
> this to fpxx and still have the modules buildable with old tools as
> well? I'm not sure if it will be acceptable to say that it has to be
> rewritten in C.

If it's assembled as -mfpxx then it'll be implicitly tagged with the
new .gnu_attribute rather than 4,1.  If it's not assembled as -mfpxx
then 4,1 would be the right choice.

Thanks,
Richard