On Tue, Sep 20, 2022 at 11:35:07AM +0800, Hongtao Liu wrote:
> > The question is (mainly for aarch64, arm and x86 backend maintainers) if we
> > shouldn't support it, in the PR there is a partial patch to do so, but
> > the big question is if it should be supported as the __bf16 type those
> > 3 targets use with u6__bf16 mangling and remove those *_invalid_* cases
> > and add conversions to/from at least SFmode but probably also DFmode, TFmode
> > and XFmode on x86 and implement arithmetics on those through conversion to
> > SFmode, performing arithmetics there and conversion back.
> > Conversion from BFmode to SFmode is easy, left shift by 16 and ought to be
> > implemented inline, SFmode -> BFmode conversion is harder,
> > I think it is roughly:
> I'm not sure if there should be any floating point exceptions for
> BFmode operation.
> For x86, there's no floating point exceptions for AVX512_BF16 related
> instructions
As long as __bf16 is just an extension, supporting or not supporting
exceptions on sNaNs is just fine I think, but I'm afraid it is different
for std::bfloat16_t. If we claim we support it (define that type
in <stdfloat>, predefine __STD_BFLOAT16_TYPE__), then it needs to follow
ISO/IEC/IEEE 60559, and I'm afraid that means also exceptions and the like.
While the IEEE spec doesn't cover the exact bfloat16 format, C++ talks about
a format with these and these number of bits here and there that behaves
like in IEEE otherwise.
Whether we support std::bfloat16_t at all is our choice, if we do support
it, whether we support it with __bf16 underlying type or come up with
something different, it is up to us, and with -ffast-math/-Ofast etc.
we can certainly use hw instructions for it which don't raise exceptions.
At least that is my limited understanding of it...
Jakub
