RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9]

[Andrew Haley]

On Mon, 8 Jul 2024 16:40:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
>> 
>>  - Merge branch 'master' into sleef-aarch64-integrate-source
>>  - merge master
>>  - sleef 3.6.1 for riscv
>>  - sleef 3.6.1
>>  - update header files for arm
>>  - add inline header file for riscv64
>>  - remove notes about sleef changes
>>  - fix performance issue
>>  - disable unused-function warnings; add log msg
>>  - minor
>>  - ... and 23 more: https://git.openjdk.org/jdk/compare/2f4f6cc3...b54fc863
>
>> While I agree with you in principle, we chose to import Sleef this way for practical reasons. (The actual importing of Sleef is happening in #19185 / [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816).) The "preprocessing/code-generation" part of the Sleef build was considered too complex to reasonably replicate in the OpenJDK build system. Sleef is built using Cmake and we do not want to add a build dependency on Cmake and call out to a foreign build system at build time, for efficiency and complexity reasons.
> 
> Of course, there is no reason to rebuild the preprocessed headers every time we build the JDK. I'd never ask for that; the last thing I want is to make building the JDK slower. However, it should be possible to do so on a checked-out JDK source tree, at the builder's option.
> 
> If there is a script, it doesn't have to be included in the OpenJDK build system itself, but it does have to be in the OpenJDK source tree. (It could be part of make/devkit, for example.)
> 
> With a script to produce preprocessed files, it should be possible for anyone building the JDK to run that script, and produce the preprocessed source. SLEEF won't take up a prohibitive amount of space.
> 
> We shouldn't be depending on some other web site somewhere being able to come up with the exact SLEEF sources we used, either. That fails the test of reproducibility.
> 
>> JDK-8329816 comes with a script to automatically generate the imported source files, to make it easy to update Sleef in the future. It should also be easy enough to verify the imported contents using the same script for anyone who wants to check the validity of the import step.
> 
> I get it, but not including everything we use in the OpenJDK tree is a dangerous precedent. It should be no big deal to do this right, given that we have the SLEEF sources and the build scripts already. I'm not asking for anything that doesn't exist already, I'm just saying that it must be checked in.
> 
> Avoiding inconvenience, however great, is not sufficient to justify such a step. This is perhaps something to discuss at the next Committers' Workshop.

> @theRealAph a precendent that exists is for binutils/llvm/capstone and hsdis. Would it be sufficient for the user to choose to build SLEEF from a separate source directory assuming all the dependencies are installed already (the source are checked-out by the user; cmake and other build dependencies are installed; etc.)? 

I believe that it's those who want to deviate from the standard best practice of providing source code in its preferred form who must come up with a compelling argument why it is necessary.

I can't tell what problem we're trying to solve by not simply checking in the source code, in its preferred form, to the OpenJDK tree. Thhis has practical advantages to do with traceability and security, and in-principle reasons to do with basic Open Source practice too. On the other side, there are no disadvantages.

We've been here before, and the response from @PaulSandoz to a similar case (checking in compiler-generated asm) was:

> I don’t think this should be considered a generally acceptable approach for Vector API operations (most code for operations does not and should not follow this approach), nor is it generally acceptable for other kinds of intrinsic in HotSpot (I believe there are a few special cases under os_cpu).

https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2021-May/047094.html

Having said that, the problem in that case was much worse, in that the corresponding source code was not available at all.

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

PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2220180978