soft-fp: Add __extendhfxf2 and __truncxfhf2

  1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
2. Add __extendhfxf2 to truncate IEEE extended into IEEE half.

These are needed by x86 _Float16:

https://software.intel.com/content/www/us/en/develop/download/intel-avx512-fp16-architecture-specification.html

support in GCC.
---
 soft-fp/extendhfxf2.c | 53 +++++++++++++++++++++++++++++++++++++++++++
 soft-fp/truncxfhf2.c  | 52 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+)
 create mode 100644 soft-fp/extendhfxf2.c
 create mode 100644 soft-fp/truncxfhf2.c
  

On Thu, 1 Jul 2021, H.J. Lu via Libc-alpha wrote:

> 1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
> 2. Add __extendhfxf2 to truncate IEEE extended into IEEE half.

OK.  Note that the second one of those should be corrected in the commit 
message to refer to __truncxfhf2 not __extendhfxf2.

> These are needed by x86 _Float16:
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-avx512-fp16-architecture-specification.html

(As I see it, supporting _Float16 on x86 is largely orthogonal to the 
existence of a new instruction set extension with full _Float16 arithmetic 
support.  The x86_64 ABI for _Float16 / _Complex _Float16 argument passing 
and return makes sense for any x86_64 processor regardless of whether the 
hardware supports full _Float16 arithmetic (this new extension), only 
conversions (F16C / Ivy Bridge) or no _Float16 operations at all (older 
processors).  IEEE binary32 is wide enough that converting from binary16 
to binary32, doing arithmetic and converting back produces correctly 
rounded results for any of the basic +-*/ operations and so would be a 
suitable fallback for implementing them, though configuring excess 
precision as done for older AArch64 processors might be more efficient - 
and when only conversions between binary16 and binary32 are available in 
hardware as in F16C, you need to use software truncation from binary64 to 
binary16 to avoid double rounding.)
  

On Thu, Jul 1, 2021 at 10:56 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 1 Jul 2021, H.J. Lu via Libc-alpha wrote:
>
> > 1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
> > 2. Add __extendhfxf2 to truncate IEEE extended into IEEE half.
>
> OK.  Note that the second one of those should be corrected in the commit
> message to refer to __truncxfhf2 not __extendhfxf2.

Thanks.  I pushed it with

1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
2. Add __truncxfhf2 to truncate IEEE extended into IEEE half.

> > These are needed by x86 _Float16:
> >
> > https://software.intel.com/content/www/us/en/develop/download/intel-avx512-fp16-architecture-specification.html
>
> (As I see it, supporting _Float16 on x86 is largely orthogonal to the
> existence of a new instruction set extension with full _Float16 arithmetic
> support.  The x86_64 ABI for _Float16 / _Complex _Float16 argument passing
> and return makes sense for any x86_64 processor regardless of whether the
> hardware supports full _Float16 arithmetic (this new extension), only
> conversions (F16C / Ivy Bridge) or no _Float16 operations at all (older
> processors).  IEEE binary32 is wide enough that converting from binary16
> to binary32, doing arithmetic and converting back produces correctly
> rounded results for any of the basic +-*/ operations and so would be a
> suitable fallback for implementing them, though configuring excess
> precision as done for older AArch64 processors might be more efficient -
> and when only conversions between binary16 and binary32 are available in
> hardware as in F16C, you need to use software truncation from binary64 to
> binary16 to avoid double rounding.)
>

We can do _Float16 emulation like __float128 if AVX512FP16 isn't available.
We need to add AVX512FP16 variants for _Float16 builtin functions in libgcc.
  

On Thu, 1 Jul 2021, H.J. Lu via Libc-alpha wrote:

> We can do _Float16 emulation like __float128 if AVX512FP16 isn't available.
> We need to add AVX512FP16 variants for _Float16 builtin functions in libgcc.

Sure.  The handling on powerpc64le of the cases where hardware binary128 
support might or might not be available could serve as an example of how 
to handle such cases in libgcc.

The x86_64 ABI describes argument passing / return for _Float16 / _Complex 
_Float16.  The i386 ABI doesn't; ABI support will need to be added if 
those types are to be supported at all on i386 (in the 32-bit case, it 
seems appropriate for the ABI to be something valid given the base 
architecture only, so argument passing on the stack like for other types, 
return in general-purpose registers or memory) - or else make sure GCC 
disallows _Float16 in the 32-bit case in the absence of defined ABI 
support.
  

On Thu, Jul 1, 2021 at 11:17 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 1 Jul 2021, H.J. Lu via Libc-alpha wrote:
>
> > We can do _Float16 emulation like __float128 if AVX512FP16 isn't available.
> > We need to add AVX512FP16 variants for _Float16 builtin functions in libgcc.
>
> Sure.  The handling on powerpc64le of the cases where hardware binary128
> support might or might not be available could serve as an example of how
> to handle such cases in libgcc.

Hongtao, Hongyu, can you take a look at how powerpc64le handles binary128?

> The x86_64 ABI describes argument passing / return for _Float16 / _Complex
> _Float16.  The i386 ABI doesn't; ABI support will need to be added if
> those types are to be supported at all on i386 (in the 32-bit case, it

https://groups.google.com/g/ia32-abi/c/Qy_r-tY5iQY

> seems appropriate for the ABI to be something valid given the base
> architecture only, so argument passing on the stack like for other types,
> return in general-purpose registers or memory) - or else make sure GCC
> disallows _Float16 in the 32-bit case in the absence of defined ABI
> support.
>

On i386,

1. Pass _Float16 and _Complex _Float16 values on stack.
2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.