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

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

[Kito Cheng]

Hi:

It's Kito, a RISC-V folks, recently RISC-V has an ISA extension draft
for IEEE half-precision operations [4], including arithmetic,
conversion, comparison...a full set of support for IEEE
half-precision.

So we are seeking the data type for IEEE half-precision, and then we
have few candidates for that:
1. _Float16
2. __fp16 (Same as ACLE)
3. Other type names maybe __float16_t

_Float16 was the best candidate since it kind of standard types from
ISO/IEC TS 18661-3, and it already supported by both clang and gcc,
however the issue is GCC don't support that on C++ mode and seems like
[1-2] it not intend to support that due to the decimal floating point
issue, C++ also has another proposal for extended floating-point types
(https://wg21.link/p1467), which included half-precision types, so in
my understanding, _Float16 won't be a portable typen between C/C++.

And the second candidate __fp16, which is the typename come from ACLE,
it has no C/C++ portable issue due to its target specific type, the
only issue is ACLE has defined that promote to float before operation,
which is not fully utilized the hardware features, so one possible
solution is RISC-V also defined __fp16 type, but with different
semantics, no promotion if HW fp16 are enabled, like _Float16 has
flexible evaluation format, then we can gain most advantage,
compilable for ARM source code, also benefit with the hardware
capability.
But users might get different slight results than ARM, since we might
not do float promotion before evaluation for __fp16.

So the last candidate is defined another typename like __float16_t,
and define the behavior almost same as _Float16 but with default
promotion rule like __fp16 from ACLE, it also has no C/C++ portable
issue, but lose a little bit compatibility with the ARM code.

What do you think about this? I guess ideally we could wait for
P1467[3] to be included in C++ standard, but it seems like we need to
wait another couple years to land.

Or maybe add a target specific type to resolve that immediate is more
realistic solution?

Thanks

[1] See "C++ note:" in commit log
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c65699efcce48d68ef57ab3ce7fc5420fac5cbf9
[2] https://gcc.gnu.org/pipermail/gcc/2021-March/234965.html
[3] https://wg21.link/p1467
[4] https://github.com/riscv/riscv-isa-manual/pull/496

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

[Jonathan Wakely]

On Fri, 12 Mar 2021 at 09:10, Kito Cheng via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi:
>
> It's Kito, a RISC-V folks, recently RISC-V has an ISA extension draft
> for IEEE half-precision operations [4], including arithmetic,
> conversion, comparison...a full set of support for IEEE
> half-precision.
>
> So we are seeking the data type for IEEE half-precision, and then we
> have few candidates for that:
> 1. _Float16
> 2. __fp16 (Same as ACLE)
> 3. Other type names maybe __float16_t
>
> _Float16 was the best candidate since it kind of standard types from
> ISO/IEC TS 18661-3, and it already supported by both clang and gcc,
> however the issue is GCC don't support that on C++ mode and seems like
> [1-2] it not intend to support that due to the decimal floating point
> issue,

I am not aware of any motivation in the C++ committee for using class
types for new floating-point types. I don't think the C++ decimal
floating-point TR is considered a success.

> C++ also has another proposal for extended floating-point types
> (https://wg21.link/p1467), which included half-precision types, so in
> my understanding, _Float16 won't be a portable typen between C/C++.

Why not just make _Float16 available in C++ as a GCC extension?

P1467 specifically says:
"The C++ implementation could use _Float16, _Float32, etc. as the
names of the extended floating-point types behind the std:: type
aliases, allowing the use of the C names in both languages."

If/when P1467 (or something like it) gets into the C++ standard we can
add std::float16 to libstdc++ as a typedef for _Float16, but even
before then we can start to add support to std::to_chars,
std::is_floating_point, std::complex, std::abs etc.

> And the second candidate __fp16, which is the typename come from ACLE,
> it has no C/C++ portable issue due to its target specific type, the

This isn't a standard name, so to use it would mean relying on
GCC-specific extensions, so I don't see why it would be better than
relying on "_Float16" as a GCC extension for C++ (and standard for C).

Similarly for __float16_t.

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

[Kito Cheng]

Hi Jonathan:

> > C++ also has another proposal for extended floating-point types
> > (https://wg21.link/p1467), which included half-precision types, so in
> > my understanding, _Float16 won't be a portable typen between C/C++.
>
> Why not just make _Float16 available in C++ as a GCC extension?

Not sure it would introduce any ABI issue or not? Especially the function
name mangling for _Decimal* types, or maybe we could just implement the
interchanged floating point type (_FloatN) part to C++ is fine?

I am happy to implement that if it's an acceptable way to go, and
I guess it could be used when GCC implements P1467 in future.

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

[Jonathan Wakely]

On Fri, 12 Mar 2021 at 09:38, Kito Cheng <kito.cheng@gmail.com> wrote:
>
> Hi Jonathan:
>
> > > C++ also has another proposal for extended floating-point types
> > > (https://wg21.link/p1467), which included half-precision types, so in
> > > my understanding, _Float16 won't be a portable typen between C/C++.
> >
> > Why not just make _Float16 available in C++ as a GCC extension?
>
> Not sure it would introduce any ABI issue or not? Especially the function
> name mangling for _Decimal* types, or maybe we could just implement the
> interchanged floating point type (_FloatN) part to C++ is fine?

I would forget about the decimal types. I thought you were just
talking about _Float16?

You will need to decide on a mangling for it in C++, which should be
co-ordinated with other compilers that are likely to support the type.
You could mangle it as "u8_Float16" which is in the namespace reserved
for vendor-extensions but if you wanted to assign a new shorter,
non-extension then it should be discussed at
https://github.com/itanium-cxx-abi/cxx-abi/issues (which will need to
happen anyway if std::float16 is expected to go into the C++
standard).

Are you planning to support this in Clang too?

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

[Jonathan Wakely]

On Fri, 12 Mar 2021 at 09:44, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Fri, 12 Mar 2021 at 09:38, Kito Cheng <kito.cheng@gmail.com> wrote:
> >
> > Hi Jonathan:
> >
> > > > C++ also has another proposal for extended floating-point types
> > > > (https://wg21.link/p1467), which included half-precision types, so in
> > > > my understanding, _Float16 won't be a portable typen between C/C++.
> > >
> > > Why not just make _Float16 available in C++ as a GCC extension?
> >
> > Not sure it would introduce any ABI issue or not? Especially the function
> > name mangling for _Decimal* types, or maybe we could just implement the
> > interchanged floating point type (_FloatN) part to C++ is fine?
>
> I would forget about the decimal types. I thought you were just
> talking about _Float16?
>
> You will need to decide on a mangling for it in C++, which should be
> co-ordinated with other compilers that are likely to support the type.
> You could mangle it as "u8_Float16" which is in the namespace reserved
> for vendor-extensions

That's documented at
http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin

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

[Kito Cheng]

Hi Jonathan:

> I would forget about the decimal types. I thought you were just
> talking about _Float16?
>
> You will need to decide on a mangling for it in C++, which should be
> co-ordinated with other compilers that are likely to support the type.
> You could mangle it as "u8_Float16" which is in the namespace reserved
> for vendor-extensions but if you wanted to assign a new shorter,
> non-extension then it should be discussed at
> https://github.com/itanium-cxx-abi/cxx-abi/issues (which will need to
> happen anyway if std::float16 is expected to go into the C++
> standard).
>
> Are you planning to support this in Clang too?

clang already supports _Float16 on C++ for a while, but only very few targets,
ARM, AArch64, SPIR and AMDGPU.

> That's documented at
> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin

Seems like it is already defined for _FloatN types, and clang already
follow that.

::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)

Thank you, Jonathan, I'll start to add that to C++ :)

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

[Jonathan Wakely]

On Fri, 12 Mar 2021 at 09:58, Kito Cheng <kito.cheng@gmail.com> wrote:
>
> Hi Jonathan:
>
> > I would forget about the decimal types. I thought you were just
> > talking about _Float16?
> >
> > You will need to decide on a mangling for it in C++, which should be
> > co-ordinated with other compilers that are likely to support the type.
> > You could mangle it as "u8_Float16" which is in the namespace reserved
> > for vendor-extensions but if you wanted to assign a new shorter,
> > non-extension then it should be discussed at
> > https://github.com/itanium-cxx-abi/cxx-abi/issues (which will need to
> > happen anyway if std::float16 is expected to go into the C++
> > standard).
> >
> > Are you planning to support this in Clang too?
>
> clang already supports _Float16 on C++ for a while, but only very few targets,
> ARM, AArch64, SPIR and AMDGPU.
>
> > That's documented at
> > http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin
>
> Seems like it is already defined for _FloatN types, and clang already
> follow that.
>
> ::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)
>
> Thank you, Jonathan, I'll start to add that to C++ :)

Oh good, that makes it easy then!

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

[Joseph Myers]

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

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

[Gabriel Ravier]

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.)
>

Re: [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