Code size issues on FP-emulation on libgcc compared to LLVM's compiler_rt

[Joseph Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com