This is the mail archive of the
mailing list for the GCC project.
Re: Do not build soft-fp code at all for powerpc64-linux-gnu
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 22 Oct 2014 13:21:39 -0400
- Subject: Re: Do not build soft-fp code at all for powerpc64-linux-gnu
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1410220104280 dot 24064 at digraph dot polyomino dot org dot uk>
On Tue, Oct 21, 2014 at 9:06 PM, Joseph S. Myers
> 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 <email@example.com>
> * config.host (powerpc*-*-linux*): Only use soft-fp for 32-bit
> * config/rs6000/t-ppc64-fp (softfp_wrap_start, softfp_wrap_end):
> Remove variables.