[WIP,Testing]: Add test for mips64

[XiWeiGu]

Try to add mips64 test.

[martin-frbg]

Thanks. Failures seen here are somewhat suspicious - in particular in the MIPS64_GENERIC build that uses only C kernels.

[XiWeiGu]

My pleasure. It was the accuracy that caused the failure when target is I6400, I6500 and P6600. They all use sdot_msa.c as DSDOTKERNRL, but the implementations appears to use single-precision instructions to process double-precision data.

[martin-frbg]

Yes the DSDOT is somewhat familiar - this used to be a problem in almost all architectures until a few years ago. I thought I had fixed them all back then, but maybe I did not touch the MSA kernel as I had no hardware to test.

[martin-frbg]

Thanks again (I wonder if the extending of individual values to double precision is necessary, or if a simple (double) cast of the multiplication would suffice to avoid truncation of the intermediate result ?). Will "fix" MIPS64_GENERIC next (missing KERNEL file leading to wrong DGEMM kernel getting built), then see if I can do away with MIPS64_GENERIC again as we already have GENERIC.

[XiWeiGu]

My pleasure. From my point of view, since SIMD instructions are used in the implementation, a simple (double) cast of the multiplication is not useful.
When I make a change to the code：

diff --git a/utest/test_dsdot.c b/utest/test_dsdot.c
index adef4e91..996594f3 100644
--- a/utest/test_dsdot.c
+++ b/utest/test_dsdot.c
@@ -35,11 +35,15 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #if defined(BUILD_SINGLE) && defined(BUILD_DOUBLE)
 CTEST(dsdot,dsdot_n_1)
 {
-       float x= 0.172555164F;
-       float y= -0.0138700781F;
+       float x[35] = { 0.172555164F };
+       float y[35] = { -0.0138700781F };
+    for (int i = 1; i < 35; i++) {
+        x[i] = 0.0F;
+        y[i] = 0.0F;
+    }
        blasint incx=1;
        blasint incy=1;
-       blasint n=1;
+       blasint n=35;
 
        double res1=0.0f, res2=-0.00239335360107;

-       res1=BLASFUNC(dsdot)(&n, &x, &incx, &y, &incy);
+       res1=BLASFUNC(dsdot)(&n, x, &incx, y, &incy);
        ASSERT_DBL_NEAR_TOL(res2, res1, DOUBLE_EPS);

Test on my i5-6600T X86_64 machine, the utest dsdot:dsdot_n_1 failed.

TEST 22/35 zdotu:zdotu_n_1 [OK]
TEST 23/35 dsdot:dsdot_n_1 [FAIL]
  ERR: test_dsdot.c:51  expected -2.393e-03, got -2.393e-03 (diff -1.035e-10, tol 1.000e-13)
TEST 24/35 swap:cswap_inc_0 [OK]
TEST 25/35 swap:sswap_inc_0 [OK]
TEST 26/35 swap:zswap_inc_0 [OK]
TEST 27/35 swap:dswap_inc_0 [OK]
TEST 28/35 rot:csrot_inc_0 [OK]
TEST 29/35 rot:srot_inc_0 [OK]
TEST 30/35 rot:zdrot_inc_0 [OK]
TEST 31/35 rot:drot_inc_0 [OK]
TEST 32/35 dnrm2:dnrm2_tiny [OK]
TEST 33/35 dnrm2:dnrm2_inf [OK]
TEST 34/35 fork:safety [OK]
TEST 35/35 fork:safety_after_fork_in_parent [OK]
RESULTS: 35 tests (34 ok, 1 failed, 0 skipped) ran in 157 ms
make[1]: *** [Makefile:52：run_test] 错误 1
make[1]: 离开目录“/home/gxw/Code/gxw-github/OpenBLAS/utest”
make: *** [Makefile:157：tests] 错误 2

When n=1, dsdot_n_1 go straight to the loop while(i < n), sdot_kernel_16 can not be tested. Maybe we should rewrite the utest dsdot:dsdot_n_1.
If something is wrong with my understanding,please pardon me.