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: Joseph Myers <joseph at codesourcery dot com>
- To: Zinovy Nis <zinovy dot nis at gmail dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Tue, 30 Jun 2015 17:44:23 +0000
- 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>
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