On 3/12/21 7:07 PM, Joseph Myers 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,
Couldn't that just be made into shared code between the C and C++
frontends ?
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.)
