This is the mail archive of the
mailing list for the glibc project.
Re: math/test-tgmath3 test case size...
- From: Carlos O'Donell <carlos at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 22 Feb 2018 01:15:41 -0800
- Subject: Re: math/test-tgmath3 test case size...
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
On 02/19/2018 01:29 PM, DJ Delorie wrote:
> 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
> 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" ;-)
Splitting out fma seems like it might be a good idea.