> 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 <jos...@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 > jos...@codesourcery.com
