RFC: [C++23] P1467R9 - Extended floating-point types and standard names

[tahonermann]

@codemzs

2. Separate out the arithmetic enablement for __bf16 into its own patch series. This could be further split into:
   a) First patch enabling arithmetic on __bf16 when hardware support is available, and
   b) Second patch implementing excess precision support for __bf16 when hardware support is lacking. Either approach would likely necessitate a flag in the target class to determine the level of bfloat16 support.

I prefer this approach. It doesn’t matter to me if that patch is also split into the 2a and 2b parts.

@codemzs

Regarding excess precision support, it promotes types like Float16 to float for usual arithmetic operations, followed by downcast in the end. This might not match exactly with how compiler-rt implements the type specification/semantics, i.e results may not reproduceable with excess precision support, edge cases may not be handled correctly, etc. But, precision for bfloat16 might not be very important for machine learning tasks, so using excess precision might be ok for now.

I don’t feel sufficiently well informed to comment on this. I briefly reviewed P1467R9, but it isn’t clear to me whether an extended floating point type that computes values using excess precision is permissible as a type named by std::bfloat16_t. We should try to get a definitive answer to that.