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

[Joseph Myers <joseph at codesourcery dot 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
joseph@codesourcery.com