This is the mail archive of the
mailing list for the GCC project.
Re: Code size issues on FP-emulation on libgcc compared to LLVM's compiler_rt
- From: Zinovy Nis <zinovy dot nis at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 1 Jul 2015 18:34:53 +0300
- Subject: Re: Code size issues on FP-emulation on libgcc compared to LLVM's compiler_rt
- Authentication-results: sourceware.org; auth=none
- References: <CAEUiFF7idsCfpFXTMB36hnw4LGukx47T6et4mgN9OT3Pwwr0Gg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1506301734010 dot 31171 at digraph dot polyomino dot org dot uk> <CAMe9rOowcAngH4tm4mPw8he-LvWJKge99evJ_Hvvni29H0ESVA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1506302001030 dot 16184 at digraph dot polyomino dot org dot uk> <CAEUiFF6z0HSNj04Z2gnwZMAQJfUJucGidWrpe-FQSv09hiRe7Q at mail dot gmail dot com>
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 <email@example.com>:
> 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 <firstname.lastname@example.org>:
>> 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__
>> 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