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: Do not build soft-fp code at all for powerpc64-linux-gnu


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


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