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
