"Thomas Preud'homme" <thomas.preudho...@arm.com> writes: >> 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?
-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 hyper-efficient. > 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. Agreed. > 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. Thanks, Richard
