This is the mail archive of the gcc@gcc.gnu.org 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


On Tue, Jun 30, 2015 at 10:44 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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.

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


-- 
H.J.


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