Re: [PATCH 2/14] [x86_64] Vector math functions (added vector cos tests)

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 1 Jun 2015, Andrew Senkevich wrote:

> Hi, Joseph, here is the patch with makefiles refactored that way.
> Ok for trunk?

Some new files in this patch are missing the first-line description of the 
file that should come before the copyright and license notices.

Looking at the later patches in the series, I'm concerned about the number 
of bits of boilerplate test code needed for every function with a vector 
version.

For example: it seems you need separate calls such as WRAPPER_DECL 
(WRAPPER_NAME (cos)) in the sysdeps/x86_64/fpu/test-*.c files for every 
case where you have a vector version of cos.  But since you define 
TEST_VECTOR_cos to say there's such a version, wouldn't it be better for 
libm-test.inc to contain such calls, conditional on the HAVE_VECTOR_* 
macros generated by gen-libm-have-vector-test.sh, so that only one such 
call is needed for each function, across all architectures and vector 
lengths?  Or even better, put those calls in a file that's automatically 
generated by a script (libm-test.inc has the information needed to decide 
if you should use WRAPPER_DECL_ff instead for a two-argument function, 
etc.).

If things could be arranged so that TEST_VECTOR_* go in a header that's 
also used by the files that define the wrappers, so that again only one 
file (maybe automatically generated) needs to contain the calls to 
VECTOR_WRAPPER* (appropriately adjusted to generate the names of the 
vector functions automatically, I suppose), and those calls are 
conditioned on whether there's a vector implementation of that function in 
that case, it would be even better.  That way, the TEST_VECTOR_* 
definitions would be the *only* architecture-specific thing needed for 
testing per (function, format) pair.

And maybe the files such as test-double-vlen8.c and 
test-double-vlen8-wrappers.c could end up in math/, just including headers 
(and maybe automatically-generated files) that (a) by defining 
TEST_VECTOR_* macros, say which functions have a definition for a given 
vector length, (b) define the macros such as REQUIRE_AVX512F that 
determine whether testing is possible on the current hardware, (c) say how 
to define the wrappers (even there, all that should be needed is a type 
name - everything else could be done in an architecture-independent and 
vector-format-independent manner using memcpy to initialize).

Doing things that way would be a bit more work now, but avoid a lot of 
duplication when there are lots of architectures with libmvec code, each 
for lots of functions and vector lengths.

-- 
Joseph S. Myers
joseph@codesourcery.com