This is the mail archive of the
gcc@gcc.gnu.org
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 16:59:34 +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>
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 <joseph@codesourcery.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