This is the mail archive of the
mailing list for the GCC project.
Re: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Thomas Preudhomme <robotux at celest dot fr>
- Cc: Matthew Fortune <matthew dot fortune at imgtec dot com>, <gcc at gcc dot gnu dot org>
- Date: Tue, 04 Mar 2014 18:20:03 +0000
- Subject: Re: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
- Authentication-results: sourceware.org; auth=none
- References: <873b32b6c5ab5233abff5083d7e7f57a at celest dot fr> <6D39441BF12EF246A7ABCE6654B023534B53F7 at LEMAIL01 dot le dot imgtec dot org> <93929e2462c9db9ad544a5fa33f91388 at celest dot fr>
Thomas Preudhomme <firstname.lastname@example.org> writes:
>> I think the ability to detect the case of generating ABI agnostic
>> code would be useful for other architectures too.
> I do not know the other architecture to know if that is the case but
> according to what you said for MIPS it seems to be the case. Right now I
> implemented it completely in the backend but that can be done in middle
> end if several architecture would benefit from it.
Yeah, that'd be great. The checking that MIPS's -mno-float should do
(but doesn't do) would be a superset of what you need, since the MIPS
case would include internal uses of floats. But it would definitely
make sense to share the bits that can be shared and (for example) to get
consistent error messages for them.
> I did not do it because I thought that other architecture might care
> more about different kind of ABI like the calling convention for long
> long on 32 bit architectures or structure or bitfield. I did not know
> if the calling convention for float parameter mattered to other
> architecture. Also in the case of ARM a structure of up to 4
> floats/double would be passed via float registers so that would be
> counted as a float but maybe not for MIPS. So a common switch for
> several architecture might be strange if each interpret it in a
> different way.
How about warning for all float types (as the float option) and
all vector types (as a separate option)? I'm not sure there's
as much value in warning specifically about "hardware" types
since that can always change in future. E.g. a while ago the
only MIPS vector of interest was V2SF, but then Loongson added
some integer ones, and now MSA is adding 128-bit vector types.
There could be wider types in future, as happened for 512-bit AVX.
>> MIPS does have an option for something similar to this which is
>> -mno-float but it does not really do what you are aiming for here.
>> -mno-float option marks a module as float ABI agnostic but actually
>> performs code gen for a soft-float ABI. It is up to the programmer to
>> avoid floating point in function signatures. Perhaps this option
>> be useful to support the enforced compatible ABI but being able to
>> relax the ABI is better still as it would require no effort from the
>> end user. I'm planning on proposing these kind of changes for MIPS in
>> the near future.
> Yeah that's different to no-float here since the body of functions can
> use float arithmetic and even function interface as long as they are not
> public. I am interesting in knowing what exactly is your use case, what
> is the difference for the calling convention with regards to float on
> MIPS architecture. Maybe it's just a matter to choose the right name for
> the switch such as -mabi-agnostic or something?
-mno-float as it stands today is really just -msoft-float with some
floating-point support removed from the library to save space.
One of the important examples is that the floating-point printf
and scanf formats are not supported, so printf and scanf do not
pull in large parts of the software floating-point library.
But the restrictions that apply to -mno-float should make it
link-compatible with -mhard-float too, as for your use case.