Renaming and unifying helper files about sleef HOT 7 CLOSED

@shibatch, I don't think it is a good idea to merge all this files just before the release.

On the other end, I am happy for you to change the names from helper to veal, a name change is no problem.

If I may, I also have a couple of considerations.

1. I think that the fact that the architectural name of the vector extension is in the current "helper" names helps in understanding what instruction set you are using in the code, so I'd avoid replacing it with the arch/bitwidth pair and leave them in the form vealavx, vealavx512, vealadvsim and so on (veal or helper, whatever you choose).
2. unifying things is usually good, so I am happy for you to merge helpersse2 and helperavx2_128 into one single file. My concern is: will this new file work on any 128-bit wide vector extension from intel? What if you mix avx2 and sse2 intrinsic in there an someone need to run sse2 only code? Or am I missing something?
3. About merging helperadvsimd and helperneon32: they come from different architectures.
   Advanced SIMD is the vector extension of the Armv8 architecture. The Armv8 architecture has 2 execution modes: AArch32 and AArch64. In AArch32 mode the hardware is able to execute binaries for the previous architecture, the Armv7 architecture. The registers and the instructions of Armv8 are an extension of the Armv7 capabilities, in a 64-bit address space when the execution mode is AArch64.
   AArch64 Advanced SIMD has 128-bit wide vector registers, but is operates also in double precision and has a richer FP instruction set. For example, in AArch64 it is possible to compute the square root in one instruction (both in single and double precision), while in NEON, which is the vector extension of Armv7, it can be done only with an iterative algorithm, and in single precision, as the vector are 64 bits wide.
   Now, merging this two helper files would result in a bunch of #ifdefs to test whether or not the AArch64 Advanced SIMD on 64-bit registers are executed or the Armv7 one are. It is doable in principle, but I'd avoid doing it now just before the release.

from sleef.

veal means meat of calves

As a non-meat eater myself, I'm not a fan of the usage of this word actually 😅

Why not just use a more explicit word like vector (or even a short version vec) instead of an acronym that nobody will understand at a first sight?

from sleef.

As a non-meat eater myself, I'm not a fan of the usage of this word actually 😅

I am now gradually understanding your personality. 😆

Do you mean that the filename will be like vectorintel_128.h?
I think vector is still too generic.
I would like to hear other people's opinions.

from sleef.

Do you mean that the filename will be like vectorintel_128.h?

vector_avx2.h... or sleef_vec_avx2.h if you fear a clashing problem with includes...

also not sure about this idea of using arch/bit, while avx2 is more familiar to how C++ compiler are typically configured via command line switch, so it rings a bell more easily when looking at the code.

from sleef.

The problem for using the name avx2 is that that file would contain the functions for other extensions.
If we divide the helper files in such a way that each file corresponds to a combination of a bit length and an extension, there would be many helper files and thus this would be bug-prone.

from sleef.

We never adopted this naming conventions for the header files. @shibatch shall we close this issue?

from sleef.

We never adopted this naming conventions for the header files. @shibatch shall we close this issue?

Yes.

from sleef.