RFR: 8353217: Build libsleef on macos-aarch64

[Vladimir Ivanov]

On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
> 
> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
> 
> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
> 
> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
> 
> Testing: hs-tier1 - hs-tier4, microbenchmarks

Thanks for the reviews.

> This makes me wonder: @iwanowww what kind of testing have you done to ensure this works correctly?

hs-tier1 - hs-tier4 (and up to hs-tier6 as part of larger set of changes). Vector API unit tests (under `test/jdk/jdk/incubator/vector/`) exercise this functionality.

>> Is leaving the sources of sleef in share/native the right thing to do?

> No, it should move to the least common directory for all platforms where it is needed. In this case, it should move to unix instead of share.

Strictly speaking, `src/jdk.incubator.vector/linux/native/libsleef` consists of 3 parts:
  (a) original SLEEF library sources (under `upstream/` sub-folder);
  (b) platform-specific generated code (under `generated/`);
  (c) custom native wrappers used to build `libsleef` library in JDK (under `lib/`).

While (c) may be Linux-specific,  SLEEF library is cross-platform and covers wide range of platforms [1]. So, strictly speaking, it's (c) which are truly platform-specific and deserve being placed under `[linux|unix]/native`. Moreover, I'm experimenting with SLEEF usage on x86, so it's possible that it will be used on linux-x64/windows-x64 eventually.  

I'm fine with it either way. But if we don't want to relocate SLEEF sources again rather soon, I suggest to place it under `share/` right away. 

[1] https://sleef.org/

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

PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2767493489