This is the mail archive of the gcc@gcc.gnu.org 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


> From: Richard Sandiford [mailto:rdsandiford@googlemail.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? 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).

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. 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.

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.
 
Best regards,

Thomas Preud'homme




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