On Thu, 30 Nov 2023 09:35:04 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
> This version looks much better, thank you! I guess cflags/SVE_CFLAGS is an
> okay-ish solution.
>
> I'm still not 100% happy though, but it might be due to my limited
> understanding. Let me write down a few numbered statements and then
> you can tell me if I'm right or wrong.
>
> 1. The aarch64 supports two different SIMD instruction set additions,
> Neon and SVE.
True.
> 2. A specific instance of an aarch64 CPU can implement Neon, or SVE,
or none of them, but not both.
All AArch64 CPUs which support SVE also supprt Neon. SVE is
incomplete, and many functions still need Neon.
> 3. SVE is superior to Neon, and is far more common these days.
No. SVE is partial, and extends Neon, and is still fairly uncommon.
> 4. We would like to ship a single version of libvmath.so, that
supports SVE if it happens to be run on a CPU with SVE.
True.
> 5. THe same version will just use the fallback code that "works"
> but has lower performance if run on a CPU without SVE (regardless of
> if it has Neon or not)
True.
> 6. If libvmath.so is built without SVE support, and is then run
> on a CPU with SVE, it will "work", but not utilize the SVE
> functionality, so have degraded performance compared to what we
> want.
True.
> 7. To be able to build libvmath.so with SVE support, we need to
> be able to compile a simple test program using `#include
> <arm_sve.h>` and `-march=armv8-a+sve`. If this fails, we cannot
> build libvmath.so with SVE support.
arm_sve.h is part of GCC. It was added to GCC in 2019.
> 8. The ability to build with SVE support should only be
> dependent on the gcc compiler and sysroot header files, and not the
> SIMD instruction set of the build machine CPU.
True. I'm not at all sure it should even depend on GCC. If I were
doing this I'd build the interposition library in pure asm.
In fact, given that SLEEF is using pure C linkage, defining the
library in pure asm is trivial, and we can get rid of all this
configury mess.
> If all these are correct, then I think the problem is that we just
> silently ignore if building with SVE fails. Instead, it should cause
> configure to fail.
>
> If, for some reason, we must support build environment that cannot
> build for SVE, then we need to have a configure flag that allows us
> to require the presence of SVE building ability, like
> --enable-sve-support, which will be "auto" by default and thus adapt
> to the platform, but can be set to on, which will cause a configure
> fail if the platform does not have SVE compilation abilities.
>
> We cannot just silently drop expected functionality depending on the
> build machine, or at the very least, we must have a way to prevent
> that from happening.
True.
Let's just drop the requirement to require GCC support for SVE. We
don't need it.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1833489792
