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 Preud'homme" <thomas dot preudhomme at arm dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Tue, 18 Mar 2014 18:41:48 +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> <87vbvtbzcc dot fsf at talisman dot default> <001c01cf428a$e9217dc0$bb647940$ at arm dot com>
"Thomas Preud'homme" <firstname.lastname@example.org> writes:
>> From: Richard Sandiford [mailto:email@example.com]
>> -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.
> Reading again your email I realized I had missed the best bits of
> this paragraph. Being able to avoid linking all the support for float
> in printf and scanf when it is not needed is indeed interesting for
> embedded use. How does this work by the way?
-mno-float causes gcc to define the macro __mips_no_float, which the
implementation can use when deciding whether to bother handling %f, etc.
I'm afraid there's nothing more sophisticated to it than that.
> Note that this is an orthogonal issue to the calling convention being
> used or the use of a FPU. I'll take the example of ARM as it's the one
> I know best (forgive me if you already know all these details).
Well, maybe orthogonal in concept, but as above, not in implementation :-)
-mno-float really means "does not use floating point in any form",
so has a stricter requirement than what you wanted.
> On ARM, the calling convention for variadic function states that
> all parameters of primitive type are either passed in GP registers
> or on the stack, no matter what is their type. That is, you cannot
> determine whether the float logic of scanf and printf is needed
> based on the type or parameters. You could have a float passed
> to printf but only its hexadecimal value being displayed by a %x
> printf modifier, for instance if you are trying to debug a
> software implementation of float arithmetic. On the opposite,
> you could pass an integer and display it as a float, for the same
> reason of debugging a software implementation of float
> As to the use of an FPU, consider the case of the
> -mfloat-abi=softfp switch on ARM target. It makes gcc
> generate instructions using the FPU to do float arithmetic but
> still passes float in GP registers for compatibility with systems
> without an FPU. You can thus see that use of FPU, calling
> convention and linking float code of printf/scanf or 3 separate
> issues. The -no-float switch on MIPS seems to conflate these
> 3 issues by telling gcc not to do any float arithmetic (-nofpu,
> like if there was a -mfpu=none), that as a consequence the
> calling convention used does not matter (the thing for which
> I would like a switch to check that fact and an automatic
> detection) and that float related code of printf/scanf should
> not be linked in (this could be useful for other target used in
> embedded scenarios).
> Since these three aspects could be useful to several
> architectures I think they should be implemented in arch
> independent code.
Definitely. The reason -mno-float is restricted to certain MIPS
configurations rather than being a general MIPS option is because the
current option is a hack. It ought to offer at least some help in
enforcing the restrictions, whereas instead it just allows any
floating-point operations to be used and compiles them in the
same way as -msoft-float.
> In ARM case the calling convention also determine how to pass
> structures of 4 or less floats/double so there would also be an
> arch-dependent part. I am not sure about whether to add a new hook or
> provide helper function in the middle end for the backend to use.
I assume for most cases the restriction is of the form "calling this
function must not use registers in class X". I think we can detect
that using the existing hooks.
A more general restriction would be "must pass arguments in the same
way for both option set A and option set B". That too could be done
using existing hooks and SWITCHABLE_TARGET, although it might not be
> A last word about the linking issue. It would be nice to
> detect the need for float part of printf/scan automatically.
> However, I don't think it is possible to detect all cases
> because, as explained above, you can't deduce what will be
> displayed based on the type of the parameter. The only
> reliable way is to parse the format string but if the format
> string is not hardcoded but constructed then there is
> nothing you can do.
> However if all call to printf have a hardcoded format string (should
> be the case for most programs) then you can say for certain that the
> float code does not need to be linked. For program where this
> automatic detection is too conservative it would then still be
> possible to use the switch to force the float code to be left out.
I agree it's possible. FWIW, as things stand, MIPS just treats hard-float
and soft-float code as link-incompatible, so I don't think we could
use it there.