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

[Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>]

2015-06-04 20:32 GMT+03:00 Joseph Myers <joseph@codesourcery.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.

But current design was discussed and approved in december 2014, and
already 5 patches with this current design were committed.
Now I have series of 14 patches ready and such refactoring at this
moment is enough significant effort. So I propose to add this
refactoring as additional patch after this series. Is it ok?


--
WBR,
Andrew