This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "gcc\ at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "macro\ at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers \(joseph\ at codesourcery dot com\)" <joseph at codesourcery dot com>, "Moore\, Catherine \(Catherine_Moore\ at mentor dot com\)" <Catherine_Moore at mentor dot com>
- Date: Wed, 05 Mar 2014 19:53:11 +0000
- Subject: Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534AAE6E at LEMAIL01 dot le dot imgtec dot org> <87mwhhg9e5 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AC1F0 at LEMAIL01 dot le dot imgtec dot org> <878ut0fj45 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AD16E at LEMAIL01 dot le dot imgtec dot org> <87ppmbdobm dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AEB92 at LEMAIL01 dot le dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B023534B4C29 at LEMAIL01 dot le dot imgtec dot org> <87r46hbybi dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B572B at LEMAIL01 dot le dot imgtec dot org> <87mwh5bslv dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B581D at LEMAIL01 dot le dot imgtec dot org> <8761nsbj9w dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B7B3A at LEMAIL01 dot le dot imgtec dot org>
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