On Tue, Jun 30, 2015 at 10:44 AM, Joseph Myers <jos...@codesourcery.com> wrote: > On Tue, 30 Jun 2015, Zinovy Nis wrote: > >> It works properly but I noticed that code the size for many arithmetic >> functions is much more larger than for soft-fp emulation provided by >> LLVM's compiler_rt library. > > Code size is discussed in the paper about soft-fp in the 2006 Summit > proceedings. In general, soft-fp is optimized for speed (having > completely separate "if" cases for addition and subtraction, both of which > appear in both __addsf3 and __subsf3, for example) and for generality > (it's used in the Linux kernel for floating-point emulation, where you > want to follow the same choice of NaN etc. as a particular processor even > where IEEE semantics don't specify a particular choice, and it has > optional support for floating-point exceptions and rounding modes - note > that __float128 support in libgcc uses the hardware exceptions and > rounding modes when available), not for size (and generality takes > precedence over speed where they conflict, hence being a bit slower than > ieeelib even after the 2006 optimization work). > > 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 -- H.J.
