written in C intrinsics for best readability.
(the same C code works for Haswell as well)

For logistical reasons the code falls back to the existing
haswell AVX2 implementation if the GCC or LLVM compiler is not new enough

dscal is a relatively simple function... make it more readable and 50% faster
by using C intrinsics and AVX512 support

Use the same transformation as was done to saxpy for daxpy

gives a low double digit performance increase

avx512 support fits nicely in the C+intrinsics code and gets a
speed improvement for vectors where the saxpy operation is not fully
memory bound

the intrinsics version of saxpy is more readable than the inline asm version,
and in the intrinsics version there's no reason anymore to ban inlining
(since the compiler has full visibility now) which gives a mid single digits
improvement in performance

Improves readability

do the same thing for SDOT that the previous patches did for DDOT; the perf gain
is in the 60% range so at least somewhat interesting

now that it's written in C + intrinsics it's easy to add AVX512 support
for DDOT

Intrinsics based code is generally easier to read for the non-math part
of the algorithm and it's easier to add, say, AVX512 to it later

makes the asm easier to read

Now that the code is written in intrinsics it's relatively easy to add AVX512 support

intrinsics make the non-math part of the code easier to follow
than all hand coded asm, and it also helps getting ready for
adding avx512 support

symbolic names for gcc inline assembly are much easier to read

Now that the kernel is written in C-with-intrinsics, adding
AVX512 support to this kernel is trivial and yields a pretty significant
performance increase

using intrinsics is a bit easier to read (at least for the non-math part of the code)
and also allows the compiler to be better about register allocation and optimizing the
non-math (loop/setup) code.

It also allows the code to honor the "no fma" flag if the user so desires.

The result of this change is (measured for a size of 16) a 15% performance increase.

And it is a step towards being able to add an AVX512 version of the code.

gcc assembly syntax supports symbolic names in addition to numeric parameter order;
it's generally more readable to have code use the symbolic names

Disable the 16x2 DTRMM kernel on SkylakeX as well

Disable the AVX512 DGEMM kernel for now

due to #1643

Fixed a few more unnecessary calls to num_cpu_avail.

* Return a somewhat sane default value for L2 cache size if cpuid returned something unexpected

Fixes #1610, the KVM hypervisor on Google Chromebooks returning zero for CPUID  0x80000006, causing DYNAMIC_ARCH
builds of OpenBLAS to hang

I don't have as many benchmarks for these as for gemm, but it should still
make a difference for small matrices.

this required switching to the generic gemm_beta code (which is faster anyway on SKX)
for both DGEMM and SGEMM

Performance for the not-retuned version is in the 30% range

This patch adds the basic infrastructure for adding the SkylakeX (Intel Skylake server)
target. The SkylakeX target will use the AVX512 (AVX512VL level) instruction set,
which brings 2 basic things:
1) 512 bit wide SIMD (2x width of AVX2)
2) 32 SIMD registers (2x the number on AVX2)

This initial patch only contains a trivial transofrmation of the Haswell SGEMM kernel
to AVX512VL; more will follow later but this patch aims to get the infrastructure
in place for this "later".

Full performance tuning has not been done yet; with more registers and wider SIMD
it's in theory possible to retune the kernels but even without that there's an
interesting enough performance increase (30-40% range) with just this change.

Handle INCX=0,INCY=0 case

Fixes #1575 (sswap/dswap failing the swap utest on x86) as suggested by atsampson.

fixes #1571 (the old zrot.S assembly does not handle incx=0 correctly)

Revert " Switch mips32 target to USE_TRMM to fix complex TRMM"

... as it was just a silly workaround for the issue seen in #1563, caused by #1419

Remove extraneous brace from previous commit of mips dsdot fix

Revert changes from PR#1419

at least one of these changes apparently is an oversimplification, leading to TRMM breakage on some platforms as observed in #1563

Fixes #1561