The only idea on size difference I have is: headers text in many of FP-emulation files from compiler_rt contains lines like:
// This file implements quad-precision soft-float addition ***with the IEEE-754 default rounding*** (to nearest, ties to even). 2015-07-01 16:59 GMT+03:00 Zinovy Nis <zinovy....@gmail.com>: > Had anyone a chance to compare FP implementation in compiler_rt? I > still wonder why the sizes differ so much, Incomplete implementation > in compiler_rt? > compiler_rt claims it is IEEE-compliant. > > 2015-06-30 23:10 GMT+03:00 Joseph Myers <jos...@codesourcery.com>: >> 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
