RFR: 8329816: Add SLEEF version 3.6.1 [v3]

[Andrew Haley]

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

> Responding to the discussion in #18605 here as this is the PR actually adding SLEEF to the JDK source.
> 
> I was initially of the opinion that the solution already provided here was enough. We could potentially have added a Git hash in addition to the version/tag to more precisely and permanently identify the exact Sleef source we are depending on. At least a Git hash wouldn't change externally.
> 
> However, Andrew's arguments have swayed me. I now think we should add a more or less complete dump of the Sleef source into the JDK repository. I'm still open to trimming it down somewhat as long as the build steps we need to run to generate the headers we need, using the Sleef build system, are still functional. I'm basically agreeing with his suggestion but will spell it out in detail here for completeness in this PR.

Sounds good, thanks.

> We should then add a script that automatically performs the necessary build steps, using the Sleef official build system, to generate the headers we need, and outputs them into the JDK source tree, in the location where we will also commit those headers. This script should document what dependencies and configuration is necessary to run it, which will include cmake and possibly other things. Performing this step doesn't need to be completely streamlined, just reasonably possible to run. It's meant to be an import/verification step. With this solution I would recommend putting the script next to the Sleef source tree instead of in make/devkit/.
> 
> The normal JDK build will just use the committed pre-generated headers.
> 
> I looked briefly at the heroic build work provided by @fitzsim and while I admire the effort, I don't think this is the right way and we already dismissed this approach earlier. Not because I didn't think it was feasible to implement, but because of the future maintenance burden. The Sleef build is non trivial so we shouldn't try to replicate it in our build. The risk of our implementation diverging in the future is too great.

OK.

I had a brief meeting with Mark Reinhold to discuss this issue. I asked him if it would ever be acceptable to check in preprocessed code without the corresponding preferred from, and the immediate answer was an emphatic "no". So that's that.

I'm neutral on just how much of SLEEF should be checked into our source tree. As long as we include the full source for whatever subset of SLEEF we use, and it is the real source in its preferred form, I'm happy.

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

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