On Tue, 30 Jun 2015, H.J. Lu wrote: > > soft-fp is expected to be used on 32-bit and 64-bit systems for which a > > few kB code size is insignificant. > > Size is very important for IA MCU. Would it be acceptable to update > soft-fp to optimize for size with > > #ifdef __OPTIMIZE_SIZE__ > #else > #endif
I don't think there's any low-hanging fruit for size optimization. If you wanted to save that 6 or 7 kB (total, across all the float and double code in libgcc, as compared to fp-bit or ieeelib and mentioned in the Summit paper) you'd structure the library completely differently, making no attempt to support rounding modes, exceptions, signs of NaNs, choice of NaN results or any particular choice for anything not specified in IEEE, and using common functions whenever appropriate for things such as unpacking / packing, or shared addition / subtraction code, instead of inlining everything with macros. The result would be a completely different library design that wouldn't have anything much to share with soft-fp. Indeed, such a library might best be written in assembly code for each architecture (much like the existing code for ARM in libgcc). It would not surprise me if carefully examining the code generated for soft-fp functions (possibly the final assembly code, possibly the optimized GIMPLE) would show up scope for a few microoptimizations in GCC where it could optimize the soft-fp code better, but I expect the effects of such microoptimizations would be fairly small. -- Joseph S. Myers jos...@codesourcery.com
