On 10 January 2018 at 12:05, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote: > 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. > Yes, having "real code" in these effective-target tests helps.
> I'll respin the testsuite changes. > Did the testing look on the targets where it did run? > Yes, they all pass (with "assembly" instead of "object") Christophe > 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. > >
