8329816: Add SLEEF version 3.6

[vidmik]

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 to move forward.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8329816: Add SLEEF version 3.6 (Enhancement - P4)

Reviewers

• Erik Joelsson (@erikj79 - Reviewer)
• Hamlin Li (@Hamlin-Li - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19185/head:pull/19185
$ git checkout pull/19185

Update a local copy of the PR:
$ git checkout pull/19185
$ git pull https://git.openjdk.org/jdk.git pull/19185/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19185

View PR using the GUI difftool:
$ git pr show -t 19185

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19185.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mikael! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@vidmik This change is no longer ready for integration - check the PR body for details.

[openjdk]

@vidmik The following label will be automatically applied to this pull request:

• build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (b02efa6b)

[Hamlin-Li]

Thanks for working on this.
Just one question, currently in sleefinline_{advsimd,sve}.h there is #define SLEEF_ALWAYS_INLINE inline, but what expected is something like #define SLEEF_ALWAYS_INLINE inline __attribute__((always_inline)) (please check shibatch/sleef#537 for details). In the future, when we change it, do we need to go through the legal process again? I guess we don't need it, but just double check it.

[vidmik]

Looks like that change is not yet in a released version of SLEEF, and in particular not in 3.6.

We do need updated approvals when we pick up new versions. Since we've gone through the process once it's typically easier/faster to do so. It will be technically easier/faster as well, now that I know how to do it and have encoded it in the createSleef.sh script.

[erikj79]

Is this missing line break a mistake or intended?

[Hamlin-Li]

Looks like that change is not yet in a released version of SLEEF, and in particular not in 3.6.

We do need updated approvals when we pick up new versions. Since we've gone through the process once it's typically easier/faster to do so. It will be technically easier/faster as well, now that I know how to do it and have encoded it in the createSleef.sh script.

Thanks, I see.
As the version 3.6 will introduce some performance regression compared to non-intrinsic version, so to bring the fix into jdk, we need either do a manual change (like cd70f5a), or wait the next version after 3.6 (which should include changes in shibatch/sleef#537), I think we prefer the latter (i.e. depends on next version after 3.6)
That means #18605 (JDK-8312425) requires sleef version next to 3.6 (could be 3.6.1 or 3.7).

I'm OK to push this pr first, if it's also convenient for you, as we will need to push the change between 3.6.1/3.7 and 3.6 again when 3.6.1/3.7 is released.

[vidmik]

Let me suggest that we wait for the next release of SLEEF to be released in that case since that release seems to be imminent. That way we'll get both the performance fixes and we can include the RISC-V header files at the same time. Fair?

[Hamlin-Li]

Let me suggest that we wait for the next release of SLEEF to be released in that case since that release seems to be imminent. That way we'll get both the performance fixes and we can include the RISC-V header files at the same time. Fair?

Yes, it makes sense to me. Thanks!

[vidmik]

Thank you Hamlin. I'll try to keep my eyes open for the announcement of the upcoming SLEEF release but do feel free to notify me if you see it first!

[Hamlin-Li]

Thank you Hamlin. I'll try to keep my eyes open for the announcement of the upcoming SLEEF release but do feel free to notify me if you see it first!

Thank you @vidmik , sure, I will do it.

[magicus]

So you'd need a different copy of sleef for each platform? The files you have put in linux/native/libvectormath, what platform are they for? Should we not put them in a platform-specific subdirectory?

[Hamlin-Li]

So you'd need a different copy of sleef for each platform?

I think it's one or more.

The files you have put in linux/native/libvectormath, what platform are they for? Should we not put them in a platform-specific subdirectory?

we could, but not necessary, as long as they have different suffixes, and normally that suffixes indicate what platform it's for.

[magicus]

Okay, suffix works fine too. But the files currently in the patch is named e.g. sleefinline_advsimd.h, which does not indicate any platform at all. Is it a generic file, and the platform specific ones are still missing from this PR?

[Hamlin-Li]

I think both sleefinline_advsimd.h and sleefinline_sve.h are specific for arm.
In the future, on riscv the corresponding file name will be sleefinline_rvvm1.h.

Only misc.h is a generic file shared among platforms.

[magicus]

Oh, you mean that the sve suffix signals that it is for ARM. I thought you were talking about having a name like sleefinline_aarch64.h.

Sure, if the only files generated by sleef are ever .h files, the logic for chosing which to include can be done entirely by #ifdefs in the source code. But if there ever needs to be different .c or .cpp files to include in the build, the build system needs to be able to determine automatically if they should be included or included, and that can only be made if the path or the file name includes the CPU moniker.

Personally, I think it would show good alignment with the prevailing norms in the JDK to also use this way of naming files for .h files. But I confess that for .h files it is more a matter of style, rather than a necessity from the build system.

[Hamlin-Li]

Thanks for the information. I think the files from sleef will be .h headers only. I'm also fine to align with prevailing norms in the JDK, it's always good to do so.

Just a reminder for us in the future discussion of #18605, maybe we should consider this dir or file naming norms (e.g. currently there are vector_math_sve.c and vector_math_neon.c under src/jdk.incubator.vector/linux/native/libvectormath), as there will be more files related to different platforms added in the future, e.g. riscv64.

[vidmik]

I, too, envision that we'll be importing header files (only). That said, I'd very much prefer not to rename them as part of the import. If anything I could see us have architecture specific directories in which we place the respective files (and a common directory for misc.h), but it's not immediately clear to me that it's worth it given that the files are used in such a narrow context in the JDK.

[magicus]

I understand that you want to avoid renaming files, if they are imported. That is a good point. Moving them to an arch subdirectory does not seem like much additional hassle (there's apparently still a lot of manual work involved in upgrading the source from the third party upstream), and might help readers that are not deeply familiar with these platforms. But then again, if we only talk about header files, it is not strictly needed, so if you don't want to do it, then skip it.