ggml: aarch64: Implement SVE F32 kernels for vector functions

[vineelabhinav]

This PR adds SVE kernel support for F32 datatype specific to vector functions on ARM architecture.
This PR comes out from #13602 as a separate contribution of only vector functions suggested by @ggerganov.
Major code changes:

1. Add SVE support for ggml_vec_dot_f32() function.
2. Add SVE support for ggml_vec_mad_f32() function.
3. Add SVE support for ggml_vec_scale_f32() function.

Performance

This PR improves performance by ~1.3x compared to the previous NEON-based implementation.
Model: falcon-mamba-7B-F32.gguf
Command: ./build/bin/llama-bench -m falcon-mamba-7B-F32.gguf -t 8,16,32,64 -p 128,1024 -n 0

• Task1: Prompt Length: 128 tokens, Generated Tokens: 1 token

Threads	Neon (Tokens/sec)	SVE  (Tokens/sec)	Ratio
8	9.24	11.81	1.28
16	17.88	22.36	1.25
32	32.54	39.34	1.21
64	53.28	60.52	1.14

• Task2: Prompt Length: 1024 tokens, Generated Tokens: 1 token

Threads	Neon (Tokens/sec)	SVE  (Tokens/sec)	Ratio
8	8.95	11.2	1.25
16	17.22	21.13	1.23
32	30.93	37.02	1.2
64	50.17	56.94	1.13

Perplexity

There is no change in model accuracy as a result of this PR.
Command: ./build/bin/llama-perplexity -s 0 -np 128 -t 64 -m falcon-mamba-7B-F32.gguf -c 128 -b 128 --chunks 16 -f scripts/wikitext-2-raw/wiki.test.raw

NEON	SVE
7.6153 +/- 0.66890	7.6153 +/- 0.66890

Contributor: Vineel Abhinav Gottala

cc: @Vithulep

[ggerganov]

Is the scalar route faster here compared to the GGML_SIMD branch below? If not, better remove it until there is an actual SVE implementation.

[vineelabhinav]

@ggerganov
Scaler route might not be faster than GGML_SIMD. We went with this approach as:

1. If we route this function to already existing GGML_SIMD Neon, We get SIMD mappings error because if we enable SVE then all SIMD mappings will belong to SVE, where we need to use all SVE code or all Scalar code. We followed the already existing nomenclature for SIMD mappings where preprocessor directive API name is same irrespective of ISA selected. i.e "#define GGML_F32_VEC_FMA" is same for all ISA's(Neon, AVX2, AVX) , based on runtime its mapped function changes.
2. Writing SVE for this function is out of scope of this PR.

Quick workaround for point (1.):

1. Use different preprocessor directive API name for SVE and neon. For example : GGML_F32_VEC_FMA_SVE for SVE. This removes confusion in SIMD mappings between Neon and SVE on ARM.

Please let me know whether to proceed with above quick workaround or leave the scalar code as it is for now?

[ggerganov]

I see. Let's merge it like this for now.

In the future, the GGML_SIMD routes should be reimplemented into something better because the logic is becoming quite overloaded and hard to follow.

[vineelabhinav]

@ggerganov Sure and thanks for the merge.