Kyrill Tkachov wrote:
On 07/07/15 14:09, Kyrill Tkachov wrote:
Hi Alan,
On 07/07/15 13:34, Alan Lawrence wrote:
As per https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01335.html
For some context, the reference for these is at:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073a/IHI0073A_arm_neon_intrinsics_ref.pdf
This patch is ok once you and Charles decide on how to proceed with the two
prerequisites.
On second thought, the ACLE document at
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf
says in 12.2.1:
"float16 types are only available when the __fp16 type is defined, i.e. when
supported by the hardware"
However, we support __fp16 whenever the user specifies -mfp16-format=ieee or
-mfp16-format=alternative, regardless of whether we have hardware support or not.
(Without hardware support, gcc generates calls to __gnu_f2h_ieee or
__gnu_f2h_alternative instead of vcvtb.f16.f32, and __gnu_h2f_ieee or
__gnu_h2f_alternative instead of vcvtb.f32.f16. However, there is no way to
support __fp16 just using those hardware instructions without caring about which
format is in use.)
Thus we cannot be consistent with both sides of that 'i.e.', unless we also
change when __fp16 is available.
I notice that the float32x4_t is unconditionally defined in our arm_neon.h,
however.
I think this is a bug and its definition should be #ifdef'd properly as well.
Hmmm. Is this becoming a question of, which potentially-existing code do we want
to break???
Cheers, Alan
