On 8 March 2016 at 16:37, Christophe Lyon <christophe.l...@linaro.org> wrote: > To illustrate what I mean, in fact we already have similar cases: > > On 7 March 2016 at 10:12, Christophe Lyon <christophe.l...@linaro.org> wrote: >> Hi, >> >> While preparing the cleanup of neon-testgen.ml, I'm adding the missing >> tests to gcc.target/aarch64/advsimd-intrinsics. >> >> All the *_p64 and *_p128 are currently missing, and I am wondering >> what's the best option. I can think of: >> 1- Update existing tests using #ifdef __ARM_FEATURE_CRYPTO > This somewhat what we currently have in vfma.c/vfms.c (but here in > fact the test is empty if the #ifdef is false) > >> 2- Update existing tests without #ifdef, but adding effective_target >> arm_crypto_ok > That's what we have with vqrdmlah.c, testing arm_v8_1a_neon_hw > >> 3- Create dedicated tests, either grouping alll p64/p128 in one single >> source, or splitting them in as many source files as there are >> intrinsics. > That's almost what we have in vcvt_f16.c, which also uses effective > target arm_neon_fp16_hw. >
For the record, I've started implementing (3). I've created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70369 to keep track of this. Christophe. > >> 1- means that we would test different things depending on how GCC is >> configured (--with-fpu) >> 2- means that we would not be able to test the subset which does not >> require crypto if for some reason we cannot force the right effective >> target >> 3- might be a bit more confusing as several places cover the same intrinsics. >> >> Thoughts? >> >> Thanks, >> >> Christophe.
