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

[Andrew Haley]

On Tue, 16 Jul 2024 08:35:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   skip TANH
>
>> Currently,
>> 
>>     * in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185) it generates the sleef inline headers from sleef 3.6.1, which is tagged in sleef repo.
>> 
>>     * And with the script in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), anyone with access to sleef repo can re-generate these inline headers by himself
> 
> Right, but think about package builders. This isn't about J Random Hacker doing it by hand.
> 
> When a package gets built, the builder machine unpacks source code. If SLEEF is included as part of JDK source, all the builder has to do is run the script and overwrite whatever preprocessed source is in there. The alternative is packaging the SLEEF source code tarball separately in the OpenJDK source package. Sure, all of this can be done, but it's a question of whether we do it once, here, now, or all the downstream builders have to do it themselves.
> 
>> ( in fact anyone can generate the inline headers from sleef from scratch without using scripts in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), our script just make it easy for the future maintenance), so it's easy for anyone to verify these inline header files used in jdk.
> 
> That script must be checked in to the OpenJDK tree.
> 
>> With these 2 points, seems the traceability is fine to me, please kindly point out if I missed some points. Maybe we can add some more clear and specific information in README or createSleef.sh in #19185 to indicate which version of sleef source we're using in jdk.
>> 
>> I'm also fine with your suggestion to add whole sleef repo into jdk (maybe we can remove some of files, but we can ignore the difference temporarily in the dicussion here). To copy the sleef repo into jdk, we still need to pre-generate the inline header files, and check them in jdk along with the sleef repo, I think you also think so too
> 
> Yes.
> 
>> (As without checking in these inline headers, we will have to bring some extra dependencies into jdk, and increase extra compilation time when building jdk). But from traceability point of view, seems to me it does not bring extra benefit than current #19185. For example, if someone want to verify the pre-generate inline headers in jdk, he need to first verify the sleef source in jdk, then the pre-generated sleef inline headers.
> 
> You don't need to verify the pre-generated inline headers, just overwrite them. The point is that the sleef source is di...

> @theRealAph Thanks for clarification.
> 
> I think there are several different parts involved in the above discussion, please kindly correct me if I misunderstood.
> 
>     1. package builders. This is about the release of jdk (both src and binary), by either openjdk, adoptium, or any other downstream vendors.
> 
>     2. jdk daily development. This is about to modify, build, run/test jdk daily by jdk developers.
> 
> For the package builders, original sleef source is 

may be

> necessary; for the jdk daily development, only pre-generated sleef inline headers are necessary.

Yes, most of the time. Some devs will want to be more thorough.

> The script to pre-generate sleef inline headers is only triggerred by package builders (and I think it involves some scripts which are not part of jdk source ? e.g. the script to trigger pre-generating script),

No: all of the scripts to generate the preprocessed source from the SLEEF source must in the OpenJDK source.

> but for jdk daily development, we just need pre-generated sleef inline headers. Am I understanding correctly above?

Yes, most of the time.

Bear in mind that convenient daily development of OpenJDK is important, because we don't want to discourage developers. But we've never treated the size of the repo as one of our primary considerations.

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

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