On Tue, 4 Feb 2014, Richard Sandiford wrote:
> So here I just provide simple C functions for each operation that has
> hard-float support. We can then restrict the softfp stuff to functions
> that really do need softfp support, meaning that softfp_exclude_libgcc2 := n
> should always be OK. As an added bonus it reduces the footprint of
> libgcc_s.so
> on hard-float targets.
Simple C functions are indeed the best thing for cases where the functions
are only part of the ABI at all because of historical accident of it being
hard to build fp-bit only for soft-float multilibs. But they're also
useful for more than just MIPS - 32-bit powerpc hard float could use them
as well, for example (it seems likely there are other cases, but powerpc
is one I know about). So I think the implementation and a makefile
fragment for them should be outside config/mips, although targets may need
to configure exactly which functions to build from this set. (For
example, e500v1 would want simple C functions for SFmode but soft-fp for
DFmode, and for __unordsf2; e500v2 would want soft-fp for __unordsf2 and
__unorddf2 but otherwise simple C functions. I don't think the initial
patch needs to build out the full configurability, as long as the files
are in the right place, outside config/mips.)
A patch putting the files in an architecture-independent place should
probably then be reviewed by Ian as libgcc maintainer.
> +#elif defined (OP_eq2)
> +int FUNC (TYPE x, TYPE y) { return x == y; }
> +#elif defined (OP_ne2)
> +int FUNC (TYPE x, TYPE y) { return x != y; }
> +#elif defined (OP_ge2)
> +int FUNC (TYPE x, TYPE y) { return x >= y; }
> +#elif defined (OP_gt2)
> +int FUNC (TYPE x, TYPE y) { return x > y; }
> +#elif defined (OP_le2)
> +int FUNC (TYPE x, TYPE y) { return x <= y; }
> +#elif defined (OP_lt2)
> +int FUNC (TYPE x, TYPE y) { return x < y; }
That's not the semantics of the comparison functions. They return an
integer value that can be compared to 0 with the original operation to get
the final result, rather than returning the result of the comparison
directly. See libgcc.texi.
--
Joseph S. Myers
[email protected]
