Hi Christophe,
On 10/01/18 10:50, Christophe Lyon wrote:
Hi Kyrill,
On 8 January 2018 at 18:55, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote:
[resending due to mailer problems...]
Hi all,
This patch adds support for the Armv8.4-A architecture [1]
in the arm backend. This is done through the new
-march=armv8.4-a option.
With this patch armv8.4-a is recognised as an argument
and supports the extensions: simd, fp16, crypto, nocrypto,
nofp with the familiar meaning of these options.
Worth noting that there is no dotprod option like in
armv8.2-a and armv8.3-a because Dot Product support is
mandatory in Armv8.4-A when simd is available, so when using
+simd (of fp16 which enables +simd), the +dotprod is implied.
The various multilib selection makefile fragments are updated
too and the mutlilib.exp test gets a few armv8.4-a combination
tests.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Christophe: Can I ask you for a huge favour to give these 3
patches a run through your testing infrastructure if you get
the chance?
As briefly discussed on IRC, I ran the tests with the original series,
and also after replacing arm_fp16fml_neon_ok object with
arm_fp16fml_neon_ok assembly.
Thank you very much!
As expected, in the 1st case, all the new tests were unsupported,
and the second version almost works, except in cases where the
compiler is configured with an 'hf' target (eg arm-none-linux-gnueabihf)
and --with-fpu=vfpXXX. In this case, arm_fp16fml_neon_ok thinks
it's safe to use -mfloat-abi=softfp, but when actually compiling the
testscases, we get the usual:
fatal error: gnu/stubs-soft.h: No such file or directory
Hmmm, this is because arm_fp16fml_neon_ok doesn't try to use arm_neon.h,
which is where the breakage with -mfloat-abi=softfp on that target
would come from.
I believe the solution is to use a similar logic to the arm_crypto_ok
that actually tries to include arm_neon.h and compile an intrinsic
from there. That way it can properly fail for -mfloat-abi=softfp.
I'll respin the testsuite changes.
Did the testing look on the targets where it did run?
Kyrill
Christophe
The changes should be fairly self-contained
(i.e. touching only -march=armv8.4-a support) but I've gotten
various edge cases with testsuite setup wrong in the past...
Thanks,
Kyrill
[1]
https://community.arm.com/processors/b/blog/posts/introducing-2017s-extensions-to-the-arm-architecture
2017-01-08 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
* config/arm/arm-cpus.in (armv8_4): New feature.
(ARMv8_4a): New fgroup.
(armv8.4-a): New arch.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/t-aprofile: Add matching rules for -march=armv8.4-a.
* config/arm/t-arm-elf (all_v8_archs): Add armv8.4-a.
* config/arm/t-multilib (v8_4_a_simd_variants): New variable.
Add matching rules for -march=armv8.4-a and extensions.
* doc/invoke.texi (ARM Options): Document -march=armv8.4-a.
2017-01-08 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
* gcc.target/arm/multilib.exp: Add some -march=armv8.4-a
combination tests.
