Code size issues on FP-emulation on libgcc compared to LLVM's compiler_rt

Joel Sherrill joel.sherrill@oarcorp.com
Tue Jun 30 19:57:00 GMT 2015



On 6/30/2015 1:42 PM, H.J. Lu wrote:
> 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

I don't dispute that optimizing for size would probably be wise
on any x86 CPU that needs soft-float. They are all relatively slow.
But posted measurements of size and speed impact of doing this
would be appreciated.

Unless I slept through it getting removed, the rtems targets
never dropped the lower end i386 to keep legacy hardware supported.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985



More information about the Gcc mailing list