All AArch64 patches are unchanged from previous version. However, in response to
discussion, the ARM patches are changed (much as I suggested
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02249.html); this version:
* Hides the existing vcvt_f16_f32 and vcvt_f32_f16 intrinsics, and
float16x4_t type, unless we have a scalar __FP16 type (i.e. unless
-mfp16-format=ieee/alternative is specified on the command line). Although this
loses us the ability to write code that uses hardware instructions to work with
either IEEE or Alternative formats according to the FPSCR bit, it is consistent
with ACLE statements that the vector types (float16x4_t and float16x8_t) should
only be available if the scalar type is, and that if the scalar type is
available, then one or other of __ARM_FP16_FORMAT_IEEE or
__ARM_FP16_FORMAT_ALTERNATIVE should be set.
(Straightforward interpretation of ACLE can be confusing because GCC has made
the choice of supporting the __FP16 type even when hardware is not available,
via software conversion routines - the -mfp16-format flag then picking which set
of sw routines are in use.)
* Makes all the new intrinsics available, similarly, only if we have a scalar
__FP16 type. This means that (in contrast to previous versions of this patch
series) we will not gain the ability to write programs that pass
half-precision-float values through as "bags of bits".
I considered the alternative of making -mfp16-format default to ieee, but that
makes the -mfp16-format=alternative option almost unusable, as one cannot link
object files compiled with different -mfp16-format :(. We could set the default
to be ieee only when neon-fp16 is specified, but that change is pretty much
orthogonal to this patch series so can follow independently if desired.
* To ease testing (including a couple of existing tests), I modified the
arm_neon_fp16_ok functions in lib/target-supports.exp to try also flags
specifying -mfp16-format=ieee (if flags without that fail to compile, presumably
because of the absence of an __FP16 type; however, this still allows an explicit
-mfp16-format=alternative if desired). On ARM targets, we then pass in
-mfpu=neon-fp16 and -mfp16-format flags for all tests in advsimd-intrinsics.exp,
unless these are overridden by an explicit multilib, in which case we will run
the advsimd-intrinsics tests without the float16 variants (via #if).
Are these patches OK for trunk? If so I will commit along with the
previously-approved fix to fold-const.c for HFmode,
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00696.html
Bootstrapped on arm-none-linux-gnueabihf (--with-arch=armv7-a --with-fpu=neon
--with-float=hard), and aarch64-none-linux-gnu; cross-tested arm-none-eabi (a
number of variants, especially for the advsimd-intrinsics tests in patch 13+14).
Thanks, Alan
- [PATCH 0/15][ARM/AArch64] Add support for float16_t vectors... Alan Lawrence
-
