On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mik...@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 https://github.com/openjdk/jdk/pull/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.

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.

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

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

Reply via email to