RFR: 8329816: Add SLEEF version 3.6.1 [v3]

Magnus Ihse Bursie ihse at openjdk.org
Wed Aug 28 12:15:21 UTC 2024


On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README to include RISC-V

I think this will need some discussion to get it right, both from a
a) source layout/organization, and
b) build system perspective.

We're doing something that is quite new to the JDK source code base and build system, after all.

Some questions that needs to be answered:

* Do we store the full source code "off tree", e.g. like in `src/utils/spleef`, just for reference? And then store the generated files that are actually compiled in the "proper" place, like `src/java.base/native/libspleef`. Doing it this way will simplify the build. It will possibly also simplify for developers, since they can look at the actual code that is compiled and used.

* Or do we store the complete code base at e.g.  `src/java.base/native/libspleef`, but filter out that from the build, and instead have the generated files in something like  `src/java.base/native/libspleef/preprocessed-src`? I think that sounds like a bad idea, in general. It would be confusing, harder to implement in the build, and overall not generally helpful for the understanding of the code base.

* Or do we only store the complete code base at e.g.  `src/java.base/native/libspleef`, and generate the preprocessed files at build time, every time we build? That would in effect mean we incorporate the libsleef build in our system, including all their dependencies. The advantage is that it would make the source code placement logical, but it would be a hard hit on how we build the product. 

* If we chose to check in pre-processed sources, where should the logic for doing the pre-processing reside? As part of configure, make, or a separate script? My spontaneous reaction is to have it as part of the build system, like  `make update-spleef-source`, but there might be more to it. For checking requirements, configure is the general go-to place.
I am not a fan of the idea of having a specially hacked shell script dropped down in the middle of the spleef sources. :-(

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

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2315158159


More information about the build-dev mailing list