On 07/07/15 17:34, Alan Lawrence wrote:
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.)
Hmmm... In my opinion intrinsics should aim to map to instructions rather than
go away and
call library functions, but this is the existing functionality
that current users might depend on :(
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???
CC'ing the ARM maintainers and Tejas for an ACLE perspective.
I think that we'd want to gate the definition of __fp16 on hardware
availability as well
(the -mfpu option) rather than just arm_fp16_format but I'm not sure of the
impact this will have
on existing users.
Kyrill
Cheers, Alan
