On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov <vliva...@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

Reply via email to