diff mbox

Do not build soft-fp code at all for powerpc64-linux-gnu

Message ID Pine.LNX.4.64.1410220104280.24064@digraph.polyomino.org.uk
State New
Headers show

Commit Message

Joseph Myers Oct. 22, 2014, 1:06 a.m. UTC
When I added support for using soft-fp in libgcc
<https://gcc.gnu.org/ml/gcc-patches/2006-03/msg00689.html>, libgcc
configuration was still done in the gcc/ directory, meaning that the
variables set in makefile fragments could not depend on the multilib
being built.  Thus, building the soft-fp code for powerpc64-linux-gnu
was disabled in the same way as had been done with fp-bit: the code
was built, but with #ifndef __powerpc64__ wrappers around it so that
the resulting objects were empty.

Now that libgcc configuration is done in the toplevel libgcc
directory, such uses of softfp_wrap_start / softfp_wrap_end are better
replaced by configure-time conditionals that determine whether to use
soft-fp for a given multilib.  This patch does so for
powerpc*-*-linux*.  The same would appear to apply to
powerpc*-*-freebsd* (using rs6000/t-freebsd64), but I have not made
any changes there.  t-ppc64-fp is also used by AIX targets, but they
don't use soft-fp anyway so the changes are of no consequence to them.

The same principle of replacing softfp_wrap_start / softfp_wrap_end
with configure-time conditionals also applies to
softfp_exclude_libgcc2, which was intended for cases where soft-fp is
being used on hard-float multilibs and so it is desirable on those
multilibs for a few functions to come from libgcc2.c rather than
soft-fp (but the soft-fp versions would be more efficient on
soft-float multilibs).  Now we have hardfp.c and t-hardfp, those are
better to use in that case, to minimize the size of the bulk of the
functions that are only present for ABI compatibility and should never
be called by newly compiled code.

I intend followup patches to switch 32-bit hard-float multilibs to use
t-hardfp as far as possible (for all non-libgcc2.c operations for
classic hard float; for all except __unord* for e500v2; for all SFmode
operations except __unordsf2 for e500v1).  After that will come making
the soft-fp operations, in the remaining cases for which they are
built because they are actually needed for code compiled by current
GCC, into compat symbols when building for glibc 2.19 or later, so
that the glibc versions (with exception and rounding mode support) get
used instead (2.19 or later is needed for all the functions to be
exported from glibc as non-compat symbols).  In turn, that is required
before implementing TARGET_ATOMIC_ASSIGN_EXPAND_FENV for soft-float
and e500, as that can only be properly effective when GCC-compiled
code is actually interoperating correctly with the exception and
rounding mode state used by <fenv.h> functions.

Tested with no regressions with cross to powerpc64-linux-gnu (in
addition, verified that stripped libgcc_s.so.1 is identical before and
after the patch).  OK to commit?

2014-10-22  Joseph Myers  <joseph@codesourcery.com>

	* config.host (powerpc*-*-linux*): Only use soft-fp for 32-bit
	configurations.
	* config/rs6000/t-ppc64-fp (softfp_wrap_start, softfp_wrap_end):
	Remove variables.

Comments

David Edelsohn Oct. 22, 2014, 5:21 p.m. UTC | #1
On Tue, Oct 21, 2014 at 9:06 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> When I added support for using soft-fp in libgcc
> <https://gcc.gnu.org/ml/gcc-patches/2006-03/msg00689.html>, libgcc
> configuration was still done in the gcc/ directory, meaning that the
> variables set in makefile fragments could not depend on the multilib
> being built.  Thus, building the soft-fp code for powerpc64-linux-gnu
> was disabled in the same way as had been done with fp-bit: the code
> was built, but with #ifndef __powerpc64__ wrappers around it so that
> the resulting objects were empty.
>
> Now that libgcc configuration is done in the toplevel libgcc
> directory, such uses of softfp_wrap_start / softfp_wrap_end are better
> replaced by configure-time conditionals that determine whether to use
> soft-fp for a given multilib.  This patch does so for
> powerpc*-*-linux*.  The same would appear to apply to
> powerpc*-*-freebsd* (using rs6000/t-freebsd64), but I have not made
> any changes there.  t-ppc64-fp is also used by AIX targets, but they
> don't use soft-fp anyway so the changes are of no consequence to them.
>
> The same principle of replacing softfp_wrap_start / softfp_wrap_end
> with configure-time conditionals also applies to
> softfp_exclude_libgcc2, which was intended for cases where soft-fp is
> being used on hard-float multilibs and so it is desirable on those
> multilibs for a few functions to come from libgcc2.c rather than
> soft-fp (but the soft-fp versions would be more efficient on
> soft-float multilibs).  Now we have hardfp.c and t-hardfp, those are
> better to use in that case, to minimize the size of the bulk of the
> functions that are only present for ABI compatibility and should never
> be called by newly compiled code.
>
> I intend followup patches to switch 32-bit hard-float multilibs to use
> t-hardfp as far as possible (for all non-libgcc2.c operations for
> classic hard float; for all except __unord* for e500v2; for all SFmode
> operations except __unordsf2 for e500v1).  After that will come making
> the soft-fp operations, in the remaining cases for which they are
> built because they are actually needed for code compiled by current
> GCC, into compat symbols when building for glibc 2.19 or later, so
> that the glibc versions (with exception and rounding mode support) get
> used instead (2.19 or later is needed for all the functions to be
> exported from glibc as non-compat symbols).  In turn, that is required
> before implementing TARGET_ATOMIC_ASSIGN_EXPAND_FENV for soft-float
> and e500, as that can only be properly effective when GCC-compiled
> code is actually interoperating correctly with the exception and
> rounding mode state used by <fenv.h> functions.
>
> Tested with no regressions with cross to powerpc64-linux-gnu (in
> addition, verified that stripped libgcc_s.so.1 is identical before and
> after the patch).  OK to commit?
>
> 2014-10-22  Joseph Myers  <joseph@codesourcery.com>
>
>         * config.host (powerpc*-*-linux*): Only use soft-fp for 32-bit
>         configurations.
>         * config/rs6000/t-ppc64-fp (softfp_wrap_start, softfp_wrap_end):
>         Remove variables.

Okay.

Thanks, David
diff mbox

Patch

Index: libgcc/config/rs6000/t-ppc64-fp
===================================================================
--- libgcc/config/rs6000/t-ppc64-fp	(revision 216519)
+++ libgcc/config/rs6000/t-ppc64-fp	(working copy)
@@ -1,5 +1,2 @@ 
 # Can be used unconditionally, wrapped in __powerpc64__ || __64BIT__ __ppc64__.
 LIB2ADD += $(srcdir)/config/rs6000/ppc64-fp.c
-
-softfp_wrap_start := '\#ifndef __powerpc64__'
-softfp_wrap_end := '\#endif'
Index: libgcc/config.host
===================================================================
--- libgcc/config.host	(revision 216519)
+++ libgcc/config.host	(working copy)
@@ -990,7 +990,10 @@ 
 	extra_parts="$extra_parts crtbeginS.o crtendS.o crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"
 	;;
 powerpc*-*-linux*)
-	tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr rs6000/t-crtstuff rs6000/t-linux t-softfp-sfdf t-softfp-excl t-dfprules rs6000/t-ppc64-fp t-softfp t-slibgcc-libgcc"
+	tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr rs6000/t-crtstuff rs6000/t-linux t-dfprules rs6000/t-ppc64-fp t-slibgcc-libgcc"
+	if test "${host_address}" = 32; then
+		tmake_file="${tmake_file} t-softfp-sfdf t-softfp-excl t-softfp"
+	fi
 	extra_parts="$extra_parts ecrti.o ecrtn.o ncrti.o ncrtn.o"
 	md_unwind_header=rs6000/linux-unwind.h
 	;;