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

due to #1643

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.

Add multithreading support for Haswell DDOT

copied from ashwinyes' implementation in dot_thunderx2t99.c

as the inaccuracies seen in the original testcase for #1332 appear to be due to an artefact that amplifies the very small rounding differences between FMA and discrete multiply+add

The OSX assembler apparently mishandles the argument to decimal .align, leading to a significant loss of performance 
as observed in #730, #901 and most recently #1470

Initialize unitialized values for repeated calls

Address warnings #1357

Tag %1 and %2 as both input and output operands

fix from #1292 extended to the other gemv microkernels

Tag %1 and %2 as both input and output

The inline assembly modifies its input operands, so mark them as output to avoid surprises with optimization. Fixes #1292

related to issue #1332

The testcase from #1332 exposes a problem in daxpy_microk_haswell-2.c that is not seen with
any of the other Intel x86_64 microkernels.

* dead increments in driver/level2

* dead increments in kernel/generic

* part dead increments in kernel/x86_64

Add optimized dsdot to all other x86_64 kernels that use sdot.c