RFR: 8353217: Build libsleef on macos-aarch64

[Magnus Ihse Bursie]

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

The rule that has dictated placement of the sources is where it is actually used in the JDK. If upstream spleef is cross-platform, or if the generated code is platform independent is strictly speaking irrelevant, if it is only used in our linux builds.

Unless you are like 95% sure you are going to use libsleef on Windows, I still think it should be put in unix rather than share. Moving it once again is not that much of a hassle. 

In contrast, if we in general allowed ourselves to not keep the source code based on what we do, but "just as a precaution if we are going to do stuff in the future", it would be much harder to reason about the code. This is a sort of "tragedy of the commons" -- every single piece of code might think that "this extra but unnecessary generalization helps me a bit and does not hurt much", but if you let that sentiment guide your code it quickly becomes much harder to maintain than necessary.

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

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