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 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
