On Fri, 1 Dec 2023 16:45:49 GMT, Magnus Ihse Bursie <i...@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
