This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: Run libm tests separately for each function
On Fri, 17 Feb 2017, Florian Weimer wrote:
> * Joseph Myers:
>
> > Any comments? Especially regarding the use of iterators; there is
> > existing precedent (in elf/Makefile) for using o-iterator.mk as a
> > generic iterator with object-suffixes-left set to something other than
> > a list of object suffixes, but maybe there should be a differently
> > named iterator for such generic uses?
>
> Does this patch depend on another change? I get a build failure on
> x86-64:
>
> In file included from ../sysdeps/x86_64/fpu/test-double-libmvec-alias-mod.c:25:0,
> from ../sysdeps/x86_64/fpu/test-double-libmvec-alias-avx512-mod.c:1:
> ../sysdeps/x86_64/fpu/test-libmvec-alias-mod.c: In function ‘init_arg’:
> ../sysdeps/x86_64/fpu/test-libmvec-alias-mod.c:33:3: error: implicit declaration of function ‘GLRO’ [-Werror=implicit-function-declaration]
> CHECK_ARCH_EXT;
> ^
That's not one of the tests affected by my patch. I see that with current
unmodified sources and suspect Zack's header changes.
> My immediate concern is that o-iterator.mk appears to have quadratic
> behavior in the number of elements. I'd like to run some build-time
> benchmarks to ensure that this has no excessive build-time impact.
Note that o-iterator.mk is used with object-suffixes-left containing at
most 17 elements (libm-tests-base, on x86_64; would be 20 elements with
float128 support added on x86_64), not with it containing anything
involving the 121 functions under test.
I'd expect this patch to improve test time for sufficiently high
parallelism, where the move from 17 separately built large tests to 1137
smaller tests (on x86_64) allows more parallelism that outweighs the
overheads of running more tests separately from the makefile. And of
course if you compare with 2.25, that had serialization for the run of
gen-libm-test.pl (which happened unnecessarily as part of the build rather
than only when testing because of the before-compile setting).
--
Joseph S. Myers
joseph@codesourcery.com