This is the mail archive of the
`libc-alpha@sourceware.org`
mailing list for the glibc project.

# Re: math/test-tgmath3 test case size...

*From*: DJ Delorie <dj at redhat dot com>
*To*: Joseph Myers <joseph at codesourcery dot com>
*Cc*: libc-alpha at sourceware dot org
*Date*: Mon, 19 Feb 2018 16:29:05 -0500
*Subject*: Re: math/test-tgmath3 test case size...
*Authentication-results*: sourceware.org; auth=none

So I did some statistics on test-tgmath3.c. There are 73 functions
tested, but the number of tests-per-function depend on the number of
arguments to that function, since we test permutations of all arguments.
There are 25 types tested for riscv.
Thus, fma(), which takes three arguments, accounts for 15,625 of the
28,823 tests (15,625 = 25*25*25). So even if we split tgmath3 up by
function name, we're still left with one source that will be huge (the
rest are: one 2200, a few 625, the rest under 50 tests-per-function).
Splitting by return type doesn't help, as 15,849 of the tests return
"double" (no surprise).
If we split by the type of the first argument, we get 47 files of at
most 1,097 tests per file. This is a good split for compiling, but not
an intuitive split, and the Makefile rules for it might be confusing or
tricky.
In theory, at least, if we split out fma, we'd have two files each of
which could compile in 1/4 the time (assuming the O(N^2) affects are
primary), and could run on two cores, resuling in 1/8th the wall clock
time. I might test this if I can improve my python-fu and find time on
the simulator.
I'll also ask the obvious "why so many permutations" but I assume the
answer is "because testing" ;-)