RFR: 8329816: Add SLEEF version 3.6.1 [v3]
Magnus Ihse Bursie
ihse at openjdk.org
Thu Aug 29 12:42:23 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
Furthermore, despite what Erik said above, I would really, really like to not have a stand-alone shell script mixed in with the spleef sources. Instead, we should treat updating the generated spleef sources as any other build-related activities, that is, we should have a build target for that.
I imagine we would have a `make update-spleef-source` that calls into UpdateSpleefSource.gmk. This in turn will more or less call `cmake` with the proper arguments needed to build spleef, and copy the resulting files into the `generated` directory.
The prerequisites required for doing this, e.g. having cmake available (and possibly any other requirements?) should be checked by configure.
There are two slightly different nuances on how we handle these dependencies: We could either add a `--enable-spleef-updating` argument to configure, which will fail configure if some dependencies are missing, and if will be responsible for making the `update-spleef-source` target available. (This would have a typical true/false/auto setup, so the target will be available if you happen to have all requirements present.)
The other alternative, if the one above would be too much, is to just set the dependencies in configure if they are found, and then verify in UpdateSpleefSource.gmk that they are non-empty (and fail with an error otherwise). This is contrary to the general design of the build system, but might be acceptable in a special case like this, to gain a bit of simplicity in the code.
I can help you with the build system changes, if what I wrote above made no sense to you.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2317538370
PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2317539214
More information about the build-dev
mailing list