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. No worry, seems works for me, I just had a very draft version tested locally. we just need to get the final inline versions of sleef generated by sleef cmake install. A question about the licensing: how long does it take to finish the legal process of the sleef licence? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2015341870
