This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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. Here is refactored version according to your comments. Is it ok? 2015-06-05 Andrew Senkevich <andrew.senkevich@intel.com> * math/Makefile: Added rules for vector tests. * math/gen-libm-have-vector-test.sh: Added generation of declaration under condition. * math/test-double-vlen2.h: New file. * math/test-double-vlen4.h: New file. * math/test-double-vlen8.h: New file. * math/test-vec-loop.h: Added initialization macro. * sysdeps/x86_64/fpu/Makefile: Added variables for vector tests. * sysdeps/x86_64/fpu/libm-test-ulps: Regenarated. * sysdeps/x86_64/fpu/math-tests-arch.h: New file. * sysdeps/x86_64/fpu/test-double-vlen2-wrappers.c: New file. * sysdeps/x86_64/fpu/test-double-vlen2.c: New file. * sysdeps/x86_64/fpu/test-double-vlen4-avx2-wrappers.c: New file. * sysdeps/x86_64/fpu/test-double-vlen4-avx2.c: New file. * sysdeps/x86_64/fpu/test-double-vlen4-wrappers.c: New file. * sysdeps/x86_64/fpu/test-double-vlen4.c: New file. * sysdeps/x86_64/fpu/test-double-vlen8-wrappers.c: New file. * sysdeps/x86_64/fpu/test-double-vlen8.c: New file. -- WBR, Andrew
Attachment:
0002-x86-64-vector-cos-tests.patch
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |