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: "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:14:56 +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> <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>
On Wed, 1 Jul 2015, Zinovy Nis wrote:
> 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.
If you examine the implementation approaches, you will see that apart from
the compiler_rt code not being set up for rounding mode and exceptions
support (and in some cases, it can be hard to completely optimize generic
code as much as code that never has to consider those issues), it (for
addition) does normalization in one place, and swaps the arguments in one
place so as to know which has the larger magnitude, whereas soft-fp tries
to reduce the amount of processing in each case by only normalizing when
and to the extent needed and duplicating code for each choice of which
argument has the larger exponent (and having separate code for the case of
equal exponents).
--
Joseph S. Myers
joseph@codesourcery.com