On 13 November 2015 at 14:36, Christophe Lyon <christophe.l...@linaro.org> wrote: > On 13 November 2015 at 12:24, Kyrill Tkachov <kyrylo.tkac...@arm.com> wrote: >> >> On 13/11/15 11:18, Ramana Radhakrishnan wrote: >>>> >>>> Hmm. I hadn't noticed that the crypto intrinsics tests where generated by >>>> neon-testgen.ml, I thought they were hand-written. >>>> The tests I added do not cover the crypto intrinsics, so I'm going >>>> to revert r230274 and restore all the tests generated by neon-testgen.ml >>>> until we have better coverage in advsimd-intrinsics. >>> >>> From what I remember from a few days back I thought it was generally >>> ok to get rid of the lot as we had test coverage for everything else >>> in gcc.target/arm . >>> >>> Thus don't bother reverting. >> >> >> +1. I'll also add that you can now remove neon.ml from config/arm. > > Sorry, I felt so guilty that I reverted the removal already. > >> And also, I think we can move the remaining hand-written tests from >> gcc.target/arm/neon/ >> into gcc.target/arm/ and remove the neon/ directory altogether. >> > I'll give a deeper look at all that, and will try not to rush to meet > e/o stage1 deadline :-) >
I've given a look at this in more detail. I've attached the list of intrinsics that would no longer be tested after removing the tests generated by neon-testgen.ml. They are mostly p64 and p128, as well as: - p8/p16 vreinterpretq. Not sure why they are not in my tests. - vrnd* - vtst[q]_p8. Not sure why they are not in my tests So there is a bit of work to create new tests before removing the ml-generated ones. Christophe >> Kyrill >> >> >>> >>> Ramana >>> >>>> Sorry for the oversight. >>>> >>>> Christophe. >>>> >>>> >>>>> Christophe. >>>>> >>>>>>> regards >>>>>>> Ramana >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Christophe. >>>>>>>> >>>>>>>>> regards >>>>>>>>> Ramana >> >>
vbslq_p64 vbsl_p64 vcombine_p64 vcreate_p64 vdupq_lane_p64 vdupq_n_p64 vdup_lane_p64 vdup_n_p64 vget_low_p64 vld1q_dup_p64 vld1q_lane_p64 vld1q_p64 vld1_dup_p64 vld1_lane_p64 vld1_p64 vld2_dup_p64 vld2_p64 vld3_dup_p64 vld3_p64 vld4_dup_p64 vld4_p64 vreinterpretq_f32_p128 vreinterpretq_f32_p64 vreinterpretq_p128_f32 vreinterpretq_p128_p16 vreinterpretq_p128_p64 vreinterpretq_p128_p8 vreinterpretq_p128_s16 vreinterpretq_p128_s32 vreinterpretq_p128_s64 vreinterpretq_p128_s8 vreinterpretq_p128_u16 vreinterpretq_p128_u32 vreinterpretq_p128_u64 vreinterpretq_p128_u8 vreinterpretq_p16_p128 vreinterpretq_p16_p64 vreinterpretq_p16_p8 vreinterpretq_p16_s16 vreinterpretq_p16_s32 vreinterpretq_p16_s64 vreinterpretq_p16_s8 vreinterpretq_p16_u16 vreinterpretq_p16_u32 vreinterpretq_p16_u64 vreinterpretq_p16_u8 vreinterpretq_p64_f32 vreinterpretq_p64_p128 vreinterpretq_p64_p16 vreinterpretq_p64_p8 vreinterpretq_p64_s16 vreinterpretq_p64_s32 vreinterpretq_p64_s64 vreinterpretq_p64_s8 vreinterpretq_p64_u16 vreinterpretq_p64_u32 vreinterpretq_p64_u64 vreinterpretq_p64_u8 vreinterpretq_p8_p128 vreinterpretq_p8_p16 vreinterpretq_p8_p64 vreinterpretq_p8_s16 vreinterpretq_p8_s32 vreinterpretq_p8_s64 vreinterpretq_p8_s8 vreinterpretq_p8_u16 vreinterpretq_p8_u32 vreinterpretq_p8_u64 vreinterpretq_p8_u8 vreinterpretq_s16_p128 vreinterpretq_s16_p64 vreinterpretq_s32_p128 vreinterpretq_s32_p64 vreinterpretq_s64_p128 vreinterpretq_s64_p64 vreinterpretq_s8_p128 vreinterpretq_s8_p64 vreinterpretq_u16_p128 vreinterpretq_u16_p64 vreinterpretq_u32_p128 vreinterpretq_u32_p64 vreinterpretq_u64_p128 vreinterpretq_u64_p64 vreinterpretq_u8_p128 vreinterpretq_u8_p64 vreinterpret_f32_p64 vreinterpret_p16_p64 vreinterpret_p64_f32 vreinterpret_p64_p16 vreinterpret_p64_p8 vreinterpret_p64_s16 vreinterpret_p64_s32 vreinterpret_p64_s64 vreinterpret_p64_s8 vreinterpret_p64_u16 vreinterpret_p64_u32 vreinterpret_p64_u8 vreinterpret_p8_p64 vreinterpret_s16_p64 vreinterpret_s32_p64 vreinterpret_s64_p64 vreinterpret_s8_p64 vreinterpret_u16_p64 vreinterpret_u64_p64 vreinterpret_u8_p64 vrnda_f32 vrndaq_f32 vrnd_f32 vrndm_f32 vrndmq_f32 vrndn_f32 vrndnq_f32 vrndp_f32 vrndpq_f32 vrndq_f32 vsliq_n_p64 vsli_n_p64 vsriq_n_p64 vsri_n_p64 vtstq_p8 vtst_p8
