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]

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


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
> 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" ;-)
> 

Because testing.

Splitting out fma seems like it might be a good idea.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]