This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 <>:
> 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 <>:
>> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]