This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat

"Thomas Preud'homme" <> writes:
>> From: Richard Sandiford []
>> -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
> arithmetic.
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]