[SVE] Add SVE support to DFT

[shibatch]

This patch adds SVE support to the DFT library.

The DFT library strongly depends on the vector length, and thus it does not mix well with vector-length agnosticism. In this patch, the utilized vector length can be specified by CONFIG macro in helpersve.h. The DFT subroutine uses a dispatcher to choose the kernel subroutine from those compiled for 2048, 1024, 512 and 256-bit vector lengths.

[fpetrogalli]

Please update the changelog file with a new "Next Release" section, adding the information that you have inserted DFT for SVE, listing for which vector lengths you have done it. Thank you!

[fpetrogalli]

Please also add a paste of the SVE runs with armie of the tests related to SVE DFT.

[shibatch]

Below is the output of testing programs. SVE is not selected when testing DFT with the current setting, since the vector length is specified to 128 bit. I am planning to add better testing of DFT subroutines.

[uduki]~/work/sleef3/sleef-Add_SVE_support_to_DFT2/build-aarch64$ ctest -j 6
Test project /import/namihei.naist.jp/home/n-sibata/work/sleef3/sleef-Add_SVE_support_to_DFT2/build-aarch64
      Start  1: iut
      Start  2: iutadvsimd
      Start  3: iutsve
      Start  4: gnuabi_compatibility_ADVSIMD
      Start  5: gnuabi_compatibility_SVE
      Start  6: gnuabi_compatibility_SVE_masked
 1/18 Test  #4: gnuabi_compatibility_ADVSIMD ......   Passed    0.04 sec
 2/18 Test  #6: gnuabi_compatibility_SVE_masked ...   Passed    0.02 sec
 3/18 Test  #5: gnuabi_compatibility_SVE ..........   Passed    0.03 sec
      Start  7: naivetestdp_1
      Start  8: naivetestdp_2
      Start  9: naivetestdp_3
 4/18 Test  #7: naivetestdp_1 .....................   Passed    0.61 sec
      Start 10: naivetestdp_4
 5/18 Test  #8: naivetestdp_2 .....................   Passed    1.22 sec
 6/18 Test  #9: naivetestdp_3 .....................   Passed    1.21 sec
      Start 11: naivetestdp_5
      Start 12: naivetestdp_10
 7/18 Test #10: naivetestdp_4 .....................   Passed    1.02 sec
      Start 13: naivetestsp_1
 8/18 Test #11: naivetestdp_5 .....................   Passed    1.13 sec
 9/18 Test #13: naivetestsp_1 .....................   Passed    0.41 sec
      Start 14: naivetestsp_2
      Start 15: naivetestsp_3
10/18 Test #15: naivetestsp_3 .....................   Passed    1.11 sec
      Start 16: naivetestsp_4
11/18 Test #14: naivetestsp_2 .....................   Passed    1.14 sec
      Start 17: naivetestsp_5
12/18 Test #16: naivetestsp_4 .....................   Passed    0.95 sec
      Start 18: naivetestsp_10
13/18 Test #17: naivetestsp_5 .....................   Passed    1.16 sec
14/18 Test #12: naivetestdp_10 ....................   Passed    6.34 sec
15/18 Test #18: naivetestsp_10 ....................   Passed    5.64 sec
16/18 Test  #1: iut ...............................   Passed  464.64 sec
17/18 Test  #2: iutadvsimd ........................   Passed  501.22 sec
18/18 Test  #3: iutsve ............................   Passed  1106.60 sec

100% tests passed, 0 tests failed out of 18

Total Test time (real) = 1106.70 sec
[uduki]~/work/sleef3/sleef-Add_SVE_support_to_DFT2/build-aarch64$ armie -s -msve-vector-bits=2048 -- bin/naivetestdp 10
Path(random) :6(0) 4(3)
ISA : AArch64 SVE 2048-bit 2048 bit double
complex  forward   : OK
complex  backward  : OK
real     forward   : OK
real     backward  : OK
real alt forward   : OK
real alt backward  : OK

0x7fa1786e8c: 0x04e0e3e8 6
...

0x7fa198aa8c: 0x043f51bf 6
armie exiting after executing 13968 SVE instructions at a rate of 1.14 per fault.
[uduki]~/work/sleef3/sleef-Add_SVE_support_to_DFT2/build-aarch64$ armie -s -msve-vector-bits=256 -- bin/naivetestdp 10
Path(random) :5(3) 3(0) 2(3)
ISA : AArch64 SVE 256-bit 256 bit double
complex  forward   : OK
complex  backward  : OK
real     forward   : OK
real     backward  : OK
real alt forward   : OK
real alt backward  : OK

0x7fa301cc90: 0x2518e140 1
...
0x7fa31de8b4: 0x04e0e3e8 6
armie exiting after executing 122301 SVE instructions at a rate of 2.09 per fault.
[uduki]~/work/sleef3/sleef-Add_SVE_support_to_DFT2/build-aarch64$

[fpetrogalli]

please mention these two items under section ### Added, as requested by the "keep a changelog" format

[fpetrogalli]

This is misleading to me. LOG2VECTLENDP is not the log-size of the vectors, but of the partial vectors you are using. I think you should add a comment saying that these VLENs are used for the DFT of the partial vectors.

[fpetrogalli]

I want to make also that the sure that the VECTLENDP = svcntd() and VECTLENDP = svcntw() don't get overwritten when building libsleef and libsleefgnuabi. Could you please raise an #error at this point if any of VECTLENDP or VECTLENSP are already defined at this point?

[fpetrogalli]

I understand you are creating a positive/negative patterns to even/odd lanes here. Any chance you could avoid using vmask for these operations (and the v*subadd operation) and use native predication by building the repeated predicate patterns withDUPQ?

See 6.21.4.4 of https://static.docs.arm.com/100987/0000/acle_sve_100987_0000_00_en.pdf

Something like:

vsubadd (x,y) = vadd(ptrue, vadd(dupq(true,false), x, y),
                            vsub(dupq(false,true), x, y)

[shibatch]

I think that's not a good idea since it includes three (or two) FP add operations, and FP operations are considered to be expensive and slow. Those operations are also dependent of the output by the previous instruction. We assume that the ALUs for the unmasked elements are not used, but that might not be the case since power-gating may take some time to kick in.

[shibatch]

I came up with a good way to remove vmask without additional FP operation.
This should reduce register pressure.

static INLINE vdouble vposneg_vd_vd(vdouble d) {
  return svneg_f64_m(d, svdupq_n_b64(false, true), d);
}