Re: [Math] float16 on ARM

From: John Maddock (jz.maddock_at_[hidden])
Date: 2019-10-15 17:05:17

>> Strange complexity within Arm: "The ARM target provides hardware support for
>> conversions between __fp16 and float values as an extension to VFP and NEON
>> (Advanced SIMD), and from ARMv8-A provides hardware support for conversions
>> between __fp16 and double values. GCC generates code using these hardware
>> instructions if you compile with options to select an FPU that provides them; for
>> example, -mfpu=neon-fp16 -mfloat-abi=softfp, in addition to the -mfp16-format
>> option to select a half-precision format."
>>
>> Unpleasant, sorry.
> I really, really don't wish to know all that! 😉  Paul

Me neither.

My first reaction was "yes of course we should do that", but on 
reflection I'm not so sure:

The intention of <boost/cstdmath.hpp> was to provide a *portable* set of 
typedefs such that each is mapped to the corresponding IEEE defined type.

And indeed, if numeric_limits<float32_t>::is_iec559 happens to be false, 
then the header will trigger a static_assert and complain that it's 
incorrectly configured.

So... we could provide a float16_t typedef, but if we're being 
consistent (and we should be), then it would only be for IEEE float16 
compatible types.

My concern is quite how we detect/configure/test that.

I also don't think we currently have any tester running on arm (for 
example), and we certainly don't have arm CI (is there any?).

Mostly thinking out loud yours, John.

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus