This is the mail archive of the gcc-patches@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: CFT: [build] Move soft-fp support to toplevel libgcc


On Tue, 12 Jul 2011, Rainer Orth wrote:

> One odd thing out is that the lm32 snippet misses
> 
> softfp_exclude_libgcc2 := y
> 
> compared to the new t-softfp-sfdf.  I'm currently handling this since I
> cannot tell if this is intentional or just an accident.

The general rule is that softfp_exclude_libgcc2 := y is to be avoided 
where possible - and after this move it should be possible (in separate 
patches) to eliminate the remaining instances of it.

Specifically, if all multilibs for a target are soft-float and using 
soft-fp, then you shouldn't need softfp_exclude_libgcc2 := y, because it's 
more efficient to implement the floating-point functions from libgcc2.c 
directly using soft-fp instead of through the libgcc2.c wrappers around 
other operations that will end up calling soft-fp functions.  The use of 
softfp_exclude_libgcc2 := y is if a target has both hard and soft float 
multilibs, because the libgcc2.c versions are better for the hard float 
multilibs and it wasn't easy to choose between them based on the multilib.

With soft-fp configuration in the toplevel libgcc directory, the libgcc 
configure script can select different configuration files depending on the 
multilib.  For the soft-float multilibs it can select the soft-fp files 
and disable the libgcc2.c versions of these functions.  For hard-float 
multilibs, the functions outside libgcc2.c aren't really needed as they 
won't actually be called; for ABI compatibility they should stay in libgcc 
if they were already there, but it would be best to keep the size of 
libgcc down by compiling them from trivial code such as "float __addsf3 
(float a, float b) { return a + b; }".  (Some cases such as Power e500v1 - 
hardware "float", software "double" - are more complicated, but the same 
general principles still apply.)

In addition to the cases for whether TFmode is involved that you noted, 
there are cases for whether TImode is involved as well.  See 
libgcc/config/i386/32/t-fprules-softfp.  With the move to toplevel, that 
file has a kludge to remove TImode functions that has no good reason to 
exist; the 32-bit multilibs should simply not include "ti" in 
softfp_int_modes, rather than including it then overriding some of the 
variables generated from that setting.

Configure tests could also make a better replacement for softfp_wrap_start 
and softfp_wrap_end.

Given the complexity of the symbol versioning setup for this code for 
x86-linux (32-bit and 64-bit) it would be a good idea to verify that the 
exported symbols in shared libgcc are the same, at the same versions, 
before and after the patch, for each of 32-bit and 64-bit.

-- 
Joseph S. Myers
joseph@codesourcery.com


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