On Mon, 27 Nov 2023 16:43:09 GMT, Andrew Haley <a...@openjdk.org> wrote:
>> Apparently the situation is this: If your build machine happens to have SVE, >> then you will get SVE support in the vmath library. The SVE support will be >> used during runtime if the machine you run on has SVE support. >> >> If your build host happens to to not have SVE, then the vmath library will >> be built without SVE support, and no matter if your runtime machine has SVE >> or not, it will not provide SVE support in the vmath library. >> >> Now, if your CI farm has an arbitrarily selection of aarch64 machines with >> and without SVE, then you have no idea what you are going to get in your >> build. >> >> We have been very careful in staying clear of this kind of "random" build >> system behavior. The system you build on should not affect the output -- at >> least, not without a chance to override the default value. >> >> In fact, I am not even sure why it seems to the PR author to be a good idea >> to let the default be dependent on the build machine at all. My personal >> opinion is that it would be better to select either "SVE enabled" or "SVE >> disabled" as the default, and then let the user override this on the >> configure command line, if they target a platform with different SVE >> availability. > >> In fact, I am not even sure why it seems to the PR author to be a good idea >> to let the default be dependent on the build machine at all. My personal >> opinion is that it would be better to select either "SVE enabled" or "SVE >> disabled" as the default, and then let the user override this on the >> configure command line, if they target a platform with different SVE >> availability. > > SVE support should be enabled regardless of the build machine. The same > binary must run on both SVE and non-SVE machines, using SVE if it is > advantageous. I suppose some ancient C++ compilers without SVE support still > exist, but I see no very good reason to support them building JDK 22+. > > Making a configure option to disable SVE support for vector math is a > mistake, but IMO mostly harmless because no-one will ever turn it off. > That's fine, but we must make sure that SVE is not used by the compiler in > any other places. If you've already built on non-SVE and tested the result on > both SVE and non-SVE, I'm happy. Agree. Since it contains both NEON and SVE functions in libvmath.so, we have to disable SVE feature when building those NEON functions. We want to separate NEON/SVE functions in two files, build them with different cflags (i.e. only build SVE sources with `-march=armv8-a+sve`), and then link to the single `libvmath.so`. Do we have such similar examples or functions in current jdk make system? I'm still struggling on finding out an effective way for it. > SVE support should be enabled regardless of the build machine. The same > binary must run on both SVE and non-SVE machines, using SVE if it is > advantageous. I suppose some ancient C++ compilers without SVE support still > exist, but I see no very good reason to support them building JDK 22+. > > Making a configure option to disable SVE support for vector math is a > mistake, but IMO mostly harmless because no-one will ever turn it off. Yes, SVE feature is also always enabled in jdk hotspot on SVE machines. If we add the option to give people disable SVE, it's weird that we disabling the SVE just in libvmath.so, and enabling it in hotspot. Besides, we choose the NEON stubs for smaller than 128-bit vector operations no matter whether the runtime machine supports SVE or not. So performance may not be an issue. Hence, I don't think people have reason disabling SVE features. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1406971807
