On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li <m...@openjdk.org> wrote:
>> Hi, >> Can you help to review this patch? >> Thanks >> >> This is a continuation of work based on [1] by @XiaohongGong, most work was >> done in that pr. In this new pr, just rebased the code in [1], then added >> some minor changes (renaming of calling method, add libsleef as extra lib in >> CI cross-build on aarch64 in github workflow); I aslo tested the combination >> of following scenarios: >> * at build time >> * with/without sleef >> * with/without sve support >> * at runtime >> * with/without sleef >> * with/without sve support >> >> [1] https://github.com/openjdk/jdk/pull/16234 >> >> ## Regression Test >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> ## Performance Test >> Previously, @XiaohongGong has shared the data: >> https://github.com/openjdk/jdk/pull/16234#issuecomment-1767727028 > > Hamlin Li has updated the pull request incrementally with one additional > commit since the last revision: > > fix jni includes Some updates: I had a look at the source code for libsleef, and frankly, to integrate building of libsleef into the OpenJDK build is going to be a major PITA. :-( They have a cmake based build system, which generates a ton of native build tools, which preprocess source code and generates output artifacts (like sleef.h). I guess we *could* do it, but I am terrified about trying to get that to work, especially for cross-compilation. So after seeing this, I think the better solution is to require a pre-compiled libsleef present in the system. (What I just called the "worse solution" an hour ago...). I guess we can make the requirement of libsleef the default value, but allow the user to override this to skip libsleef. At least then it is an active choice to disable libsleef for your build. Or, we could do something like how we used to do for freetype: have a --with-libsleef-src that points to a checked out version of libsleef, and let configure build it. In this case we could even build it as a static archive, so there'd be no need for libvectormath.so to have any external dependencies. In any case, we are going to have to consider carefully how to proceed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2014876520
