> From: Richard Sandiford [mailto:rdsandif...@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
