[RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Kito Cheng]

> The RISC-V document linked to suggests that won't be an issue for RISC-V
> with hardware _Float16 support, though obviously it's still necessary to
> decide what to do when using _Float16 on RISC-V systems without the
> hardware support, if that is allowed at all.

My thought is that _Float16 is enabled or not will depend on targets(*1), like
current support on C.

(*1) Use TARGET_SCALAR_MODE_SUPPORTED_P to check.

For RISC-V target, we prefer support _Float16 even without any hardware support,
then we just only need to provide a soft float promotion/truncation
for HF <-> SF.


excess precision is a good point that https://wg21.link/p1467 didn't
mention any word on that,
but I guess we could limit that only _Float16 is the only type that is only
affected by excess precision in C++?



On Sat, Mar 13, 2021 at 2:07 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote:
>
> > Why not just make _Float16 available in C++ as a GCC extension?
>
> There may be questions about promotions from _Float16 to wider formats for
> arithmetic.
>
> For C, there are no such promotions at the level of types (adding two
> _Float16 values produces a result of type _Float16), but the excess
> precision mechanism is used in some cases to cause a result of _Float16
> arithmetic, although of semantic type _Float16, to be represented with the
> range and precision of _Float32, to reduce the number of conversions of
> intermediate results back to the range and precision of _Float16 that are
> needed on hardware that doesn't have arithmetic operating directly on
> _Float16.  Specifically, on AArch64, the excess precision mechanism is
> used before ARMv8.2-A; v8.2-A adds direct arithmetic on _Float16 so no
> excess precision is used from then on (see aarch64_excess_precision).
>
> As we don't have excess precision support in the C++ front end, supporting
> _Float16 for C++ will require a decision about how to handle _Float16
> arithmetic on hardware where there aren't actual _Float16 arithmetic
> operations.
>
> (The RISC-V document linked to suggests that won't be an issue for RISC-V
> with hardware _Float16 support, though obviously it's still necessary to
> decide what to do when using _Float16 on RISC-V systems without the
> hardware support, if that is allowed at all.)
>
> --
> Joseph S. Myers
> joseph@codesourcery.com