RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v6]

[Xiaohong Gong]

On Fri, 1 Dec 2023 16:45:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The final thing we need to resolve properly is the SVE compiler test.
> 
> @theRealAph says:
> 
> > arm_sve.h is part of GCC. It was added to GCC in 2019.
> 
> A more relevant question is what version of gcc it was added, and if that also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
> 
> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?

Yes, the SVE compiler test code could be treated as a gcc/clang version check. `arm_sve.h` which is included in `sleef.h` and then in `vect_math_sve.c` is the SVE ACLE (Arm C Language Extensions) header file. It was included in gcc start from version 10 (may not be exact, but gcc 8/9 would fail when compile c code including this header). We have to make sure the compiler supports the SVE ACLE before using it.  Here are the different scenarios:

1. The SVE compiler test success, and `SVE_CFLAGS` is set to `-march=armv8-a+sve`. All symbols in `libvmath.so` are built successfully including NEON/SVE. Hence, the vector math operations with all kinds of vector size on both NEON/SVE machines will be improved as expected.
2. The SVE compiler test fail, and `SVE_CFLAGS` is null. SVE symbols in `libvmath.so` cannot be built out. Only NEON symbols exist in `libvmath.so`. Hence, the enhancement for vector math operations with > 128-bit vector size on SVE machines are missing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1838061502