http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52163
--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot
com> 2012-02-08 15:34:32 UTC ---
On Wed, 8 Feb 2012, amodra at gmail dot com wrote:
> Correct. In fact, I think it's a waste of space to put the soft-float
> functions in the normal ppc32 libgcc. They really only belong in the nof
> libgcc.
My view is that while they may need to stay for ABI compatibility, it
should be possible to build very small versions for that case from generic
C code for all the functions where GCC will reliably generate the expected
code (not a recursive call) from generic C - so they don't actually take
up much space in libgcc.
SFtype __addsf3 (SFtype a, SFtype b) { return a + b; }
etc.
Doing this for Power is more complicated than for some architectures
because of all the floating point variants including Xilinx and e500v1
which do only single-precision in hardware - and some variants may do some
operations in hardware but not others, for a given type (e.g.
__builtin_isunordered may involve a libgcc function for e500). But it's
certainly feasible at the present state of the toplevel libgcc transition
to control what functions are built from what sources on a per-multilib
basis, testing the compiler used for that multilib to determine which
floating-point configuration is applicable. And similar issues of not
needing certain functions in libgcc, other than for compatibility, apply
to other targets as well (MIPS in particular) - the generic C versions
referred to above will be of use for more targets than just Power.
