as trivial copy of ?asum with the fabs calls removed

Disable the AVX512 DGEMM kernel (again)

Due to as yet unresolved errors seen in #1955 and #2029

Fix bug #2047.

Signed-off-by: Celelibi <celelibi@gmail.com>

Fix inline assembly constraints in Bulldozer TRSM kernels

Fix inline assembly constraints in various x86_64 GEMVN kernels

rework indices to allow marking i,as and bs as both input and output (marked operand n1 as well for simplicity). For #2009

rework indices to allow marking argument lda as input and output.

rework indices to allow marking argument lda4 as input and output. For #2009

Fix wrong constraints in inline assembly of Haswell DTRSM kernel

for #2009

Fix unannounced modification of input operand 8 (lda4) in Haswell GEMVN microkernel

Fixes miscompilation with gcc9 -ftree-vectorize (related to issue #2009)

This fixes a crash in dblat2 when OpenBLAS is compiled using
-march=znver1 -ftree-vectorize -O2

See also:
https://github.com/easybuilders/easybuild-easyconfigs/issues/7180

Argument 0 is modified so should be input and output

Arguments 0 and 1 are both input and output

Argument 0 is modified as it doubles as a counter

Arguments 0 and 1 need to be tagged as both input and output

* Tag arguments 0 and 1 as both input and output

* Tag arguments 0 and 1 as both input and output (see #1964)

* Tag operands 0 and 1 as both input and output

For #1964 (basically a continuation of coding problems first seen in #1292)

casting ints is cheaper but it has a rounding, not memory casing effect, resulting in
invalid outcome

The dgemm_ncopy_8_skylakex.c code is not avx512 specific and gives
a nice performance boost for medium sized matrices

it's more efficient for certain tall/skinny matrices

sgemm_ncopy_4_skylakex.c uses SSE transpose operations where the
real perf win happens; this also works great for Haswell.

This gives double digit percentage gains on small and skinny matrices

with a few small changes it's possible to use the skylake sgemm code
also for haswell, this gives a modest gain (10% range) for smallish
matrixes but does wonders for very skinny matrixes

OpenBLAS has a fancy algorithm for copying the input data while laying
it out in a more CPU friendly memory layout.

This is great for large matrixes; the cost of the copy is easily
ammortized by the gains from the better memory layout.

But for small matrixes (on CPUs that can do efficient unaligned loads) this
copy can be a net loss.

This patch adds (for SKYLAKEX initially) a "sgemm direct" mode, that bypasses
the whole copy machinary for ALPHA=1/BETA=0/... standard arguments,
for small matrixes only.

What is small? For the non-threaded case this has been measured to be
in the M*N*K = 28 * 512 * 512 range, while in the threaded case it's
less, around M*N*K = 1 * 512 * 512

fixes #1902

in the threading code there are cases where N or M can become 0,
and the optimized beta code did not handle this well, leading
to a crash

during the audit for the crash a few edge conditions on the if statements
were found and fixed as well

In QA the final bug was found so now the sklyakex sgemm C based kernel can
be activated....

for most sizes this is 1.2x to 1.4x faster than the current code

very minor gains since it's not super hot code, but general principles

the compare is more costly than the work

Add optimized n/t copy versions for skylakex; in the patch the
tcopy is also rewritten using intrinsics; the ncopy file
will be worked on in a future commit

Minor gains for small matrixes, but at 512x512 and above the gain
gets more significant.

The next step for the avx512 dgemm code is adding a 16x8 kernel.
In the 8x8 kernel, each FMA has a matching load (the broadcast);
in the 16x8 kernel we can reuse this load for 2 FMAs, which
in turn reduces pressure on the load ports of the CPU and gives
a nice performance boost (in the 25% range).

This patch adds dgemm_kernel_4x8_skylakex.c which is
* dgemm_kernel_4x8_haswell.s converted to C + intrinsics
* 8x8 support added
* 8x8 kernel implemented using AVX512

Performance is a work in progress, but already shows a 10% - 20%
increase for a wide range of matrix sizes.

Add an AVX512 enabled DSYMV (L) function

Add an AVX512 enabled DGEMV (n)  function

Fix typo in sdot function