libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf [PR107703]

While DI <-> BF conversions can be handled (and are) through
DI <-> XF <-> BF and for narrower integral modes even sometimes
through DF or SF, because XFmode has 64-bit mantissa and so all
the DImode values are exactly representable in XFmode.
That is not the case for TImode, and while e.g. the HF -> TI
conversions are IMHO useless in libgcc, because HFmode has
-65504.0f16, 65504.0f16 range, all the integers will be already
representable in SImode (or even HImode for unsigned) and so
I think HF -> DI -> TI conversions are faster and valid,
BFmode has roughly the same range as SFmode and so we absolutely need
the TI -> BF conversions to avoid double rounding.

As for BF -> TI conversions, they can be either also implemented
in libgcc, or they can be implemented (as done in this commit)
as BF -> SF -> TI conversions with the same code generation used
elsewhere, just doing the 16-bit left shift of the bits - I think
we don't need to handle sNaNs during the BF -> SF part because
SF -> TI (which is already a libcall too) will handle that too.

The BF -> SF -> TI path avoids wasting
    32: 0000000000015e10   321 FUNC    GLOBAL DEFAULT   13 __fixbfti@@GCC_13.0.0
    89: 0000000000015f60   299 FUNC    GLOBAL DEFAULT   13 __fixunsbfti@@GCC_13.0.0

2023-03-10  Jakub Jelinek  <jakub@redhat.com>

	PR target/107703
	* optabs.cc (expand_fix): For conversions from BFmode to integral,
	use shifts to convert it to SFmode first and then convert SFmode
	to integral.

	* soft-fp/floattibf.c: New file.
	* soft-fp/floatuntibf.c: New file.
	* config/i386/libgcc-glibc.ver: Export __float{,un}tibf @ GCC_13.0.0.
	* config/i386/64/t-softfp (softfp_extras): Add floattibf and
	floatuntibf.
	(CFLAGS-floattibf.c, CFLAGS-floatunstibf.c): Add -msse2.

0 files changed, 0 insertions, 0 deletions