RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4]
Patrick Zhang
qpzhang at openjdk.org
Thu Nov 21 05:08:36 UTC 2024
On Wed, 20 Nov 2024 16:20:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
> First of all, building stuff with `--with-extra-cflags` is always at your own peril. It might, or might not, work, partially due to problems such as the one you describe, where the user-added flag somehow conflicts with the existing flag. If you wish to modify the build in ways that is not compatible with the existing build logic, you might end up needed a local patch to be applied, and not just adding the `--with-extra-cflags` command line.
>
> With that said, we will try to make it as possible as reasonable to write the build system for flexibility.
>
> In this case: what do you propose we would have done instead? My understanding is that the compiler needs to be told about SVE in order to compile libsleef properly.
It is right to tell the compiler about `+sve` for libsleef compilation, while the concerning point is `-march=armv8-a`. I agreed that using `armv8-a` could be a safer way to a build-system. However it invalidates the ability of `--with-extra-cflags` of specifying any proper `-march=` or `-mcpu=`. Note that the user knows very well about what to build and where to run, but has no way to change things without modifying sources. For example, if one sets `--with-extra-cflags=-march=armv9.1-a` for any equivalent `-mcpu=`, why libsleef still wants to use `armv8-a` with downgraded version of ISA? I don't think one should use "a local path" here as it would be contrary to the intent of having autoconf and the design of `--with-extra-cflags`.
Frankly speaking, no better idea from me either. Trying to update user specified `-march=` might be a way, such as `-march=armv9.1-a+sve` in above example, but perhaps it generates a new violation of the rules - `not to modify user inputs`. Leaving the "cc1: warning" message there for the time being could be also fine as it only impacts libsleef, while it warns the potential issue, for any future resolving.
FYI, aarch64 modifiers
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#g_t-march-and--mcpu-Feature-Modifiers
arch value | Architecture | Includes by default
-- | -- | --
‘**armv8-a**’ | Armv8-A | ‘+fp’, ‘+simd’
‘armv8.1-a’ | Armv8.1-A | ‘armv8-a’, ‘+crc’, ‘+lse’, ‘+rdma’
‘armv8.2-a’ | Armv8.2-A | ‘armv8.1-a’
‘armv8.3-a’ | Armv8.3-A | ‘armv8.2-a’, ‘+pauth’
‘armv8.4-a’ | Armv8.4-A | ‘armv8.3-a’, ‘+flagm’, ‘+fp16fml’, ‘+dotprod’
‘armv8.5-a’ | Armv8.5-A | ‘armv8.4-a’, ‘+sb’, ‘+ssbs’, ‘+predres’
‘armv8.6-a’ | Armv8.6-A | ‘armv8.5-a’, ‘+bf16’, ‘+i8mm’
‘armv8.7-a’ | Armv8.7-A | ‘armv8.6-a’
‘armv8.8-a’ | Armv8.8-a | ‘armv8.7-a’, ‘+mops’
‘armv8.9-a’ | Armv8.9-a | ‘armv8.8-a’
‘armv9-a’ | Armv9-A | ‘armv8.5-a’, ‘**+sve**’, ‘+sve2’
‘armv9.1-a’ | Armv9.1-A | ‘armv9-a’, ‘+bf16’, ‘+i8mm’
‘armv9.2-a’ | Armv9.2-A | ‘armv9.1-a’
‘armv9.3-a’ | Armv9.3-A | ‘armv9.2-a’, ‘+mops’
‘armv9.4-a’ | Armv9.4-A | ‘armv9.3-a’
‘armv8-r’ | Armv8-R | ‘armv8-r’
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2490088547
More information about the build-dev
mailing list