libmvec on aarch64 without hardware SVE support

libmvec on aarch64 without hardware SVE support

[Wilco Dijkstra]

Hi Andreas,

> > configure:331: aarch64-unknown-linux-gnu-gcc  -mcpu=native -pipe -O2 -Wl,-O1 -Wl,--as-needed -c -march=armv8.2-a+sve conftest.s 1>&5

I believe you can only get that if you accidentally add -mcpu=native to CC
rather than to CFLAGS.

> I don't know how typical -mcpu=... usage in comparison to -march=... is, 
> the failure I got with the CFLAGS forcing sve off probably falls under 
> "self-inflicted pain" then. If the intention of the -march=armv8.2-a+sve 
> in the configure test is to override user settings, it should fully do it
> though.

We don't add CFLAGS here, so this works fine. If we used CFLAGS then
these tests would have to use -mcpu since that takes precedence over
-march.

Cheers,
Wilco

Re: libmvec on aarch64 without hardware SVE support

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]


> Hi Andreas,
> 
> > > configure:331: aarch64-unknown-linux-gnu-gcc  -mcpu=native -pipe -O2 -Wl,-O1 -Wl,--as-needed -c -march=armv8.2-a+sve conftest.s 1>&5
> 
> I believe you can only get that if you accidentally add -mcpu=native to CC
> rather than to CFLAGS.
> 
> > I don't know how typical -mcpu=... usage in comparison to -march=... is, 
> > the failure I got with the CFLAGS forcing sve off probably falls under 
> > "self-inflicted pain" then. If the intention of the -march=armv8.2-a+sve 
> > in the configure test is to override user settings, it should fully do it
> > though.
> 
> We don't add CFLAGS here, so this works fine. If we used CFLAGS then
> these tests would have to use -mcpu since that takes precedence over
> -march.

Hi Wilco, 

Oh. Right. Thank you! Then it's indeed even more harmless since it is
(if at all) a Gentoo-only problem.

(Following advice from here long ago, we add for glibc the base CFLAGS 
to CC. I'd have to look up the rationale again myself; in general this
works very well though.)

So let's close this thread. Nothing to see here, nothing to do here, 
just move along please.

Best,
Andreas

--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: libmvec on aarch64 without hardware SVE support

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]


"Andreas K. Huettel via Libc-alpha" <libc-alpha@sourceware.org> writes:

> [[PGP Signed Part:Undecided]]
> Hi Joe, 
>
> thanks a lot.
>
>> > configure:331: aarch64-unknown-linux-gnu-gcc  -mcpu=native -pipe -O2 -Wl,-O1 -Wl,--as-needed -c -march=armv8.2-a+sve conftest.s 1>&5
>
>> > Setting both CFLAGS and CXXFLAGS to "-O2 -march=native -pipe" makes
>> > configure succeed (but of course at some point generates code that
>> > does not actually run on the machine). 
>
> I don't know how typical -mcpu=... usage in comparison to -march=... is, 
> the failure I got with the CFLAGS forcing sve off probably falls under 
> "self-inflicted pain" then. If the intention of the -march=armv8.2-a+sve 
> in the configure test is to override user settings, it should fully do it
> though.

On ARM, -mcpu is preferred to -march.

See https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/compiler-flags-across-architectures-march-mtune-and-mcpu.

It's pretty common IME.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: libmvec on aarch64 without hardware SVE support

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

Hi Joe, 

thanks a lot.

> > configure:331: aarch64-unknown-linux-gnu-gcc  -mcpu=native -pipe -O2 -Wl,-O1 -Wl,--as-needed -c -march=armv8.2-a+sve conftest.s 1>&5

> > Setting both CFLAGS and CXXFLAGS to "-O2 -march=native -pipe" makes
> > configure succeed (but of course at some point generates code that
> > does not actually run on the machine). 

I don't know how typical -mcpu=... usage in comparison to -march=... is, 
the failure I got with the CFLAGS forcing sve off probably falls under 
"self-inflicted pain" then. If the intention of the -march=armv8.2-a+sve 
in the configure test is to override user settings, it should fully do it
though.

> > Tests pass though [*].
> Hmm, SVE tests should maybe exit with UNSUPPORTED, not PASS, if not on 
> SVE hardware. I'll have a look at this.

Sounds good, not urgent.

> > What happens if code calls the vector functions on a machine that does
> > not have the hardware support?
> 
> There is no fallback - if a user is writing vector code to be run on a 
> target without SVE, we just expect them not to call out to the SVE 
> versions (IMO reasonable - same as expecting them not to turn on 
> -march=armv8-a+sve). If they do they will get an illegal instruction.
> 
> > How is an analogue case handled on x86-64?
> 
> I believe this is the approach taken for the routines in sysdeps/x86_64 
> as well - for instance there will still be 'e' variants of the libmvec 
> symbols available on machines without AVX512.

OK, makes sense.

Best,
Andreas

-- 
PD Dr. Andreas K. Huettel
Institute for Experimental and Applied Physics
University of Regensburg
93040 Regensburg
Germany

tel. +49 151 241 67748 (mobile)
tel. +49 941 943 1618 (office)
e-mail andreas.huettel@ur.de
https://www.akhuettel.de/
https://www.akhuettel.de/group/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: libmvec on aarch64 without hardware SVE support

[Joe Ramsay]

Hi Andreas,

On 21/07/2023 03:34, Andreas K. Huettel wrote:
> Setting both CFLAGS and CXXFLAGS to "-O2 -march=native -pipe" makes
> configure succeed (but of course at some point generates code that
> does not actually run on the machine). Tests pass though [*].
Hmm, SVE tests should maybe exit with UNSUPPORTED, not PASS, if not on 
SVE hardware. I'll have a look at this.
> Which makes me wonder...
>> * Added libmvec vector math library support to AArch64.  It requires
>>    GCC version >= 10.1.0.  It can be disabled via --disable-mathvec,
>>    however that is not a supported configuration as it changes the
>>    ABI.
>>    The symbol names follow the AArch64 vector ABI, they are declared
>>    in math.h and have to be called manually at this point.
>>
>> What's the plan here for machines that do not support the SVE command set
>> in hardware?
Both SVE- and non-SVE machines get the same ABI and the same routines, 
so yes a user may find that the library contains code they cannot run.
> Is there a fallback that preserves the ABI?
> What happens if code calls the vector functions on a machine that does
> not have the hardware support?

There is no fallback - if a user is writing vector code to be run on a 
target without SVE, we just expect them not to call out to the SVE 
versions (IMO reasonable - same as expecting them not to turn on 
-march=armv8-a+sve). If they do they will get an illegal instruction.

> How is an analogue case handled on x86-64?

I believe this is the approach taken for the routines in sysdeps/x86_64 
as well - for instance there will still be 'e' variants of the libmvec 
symbols available on machines without AVX512.

Hope that clears things up.

Thanks,

Joe

libmvec on aarch64 without hardware SVE support

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 2996 bytes --]

Apparently this was caused by   CFLAGS="-O2 -mcpu=native -pipe"

configure:321: checking for SVE support in assembler
configure:331: aarch64-unknown-linux-gnu-gcc  -mcpu=native -pipe -O2 -Wl,-O1 -Wl,--as-needed -c -march=armv8.2-a+sve conftest.s 1>&5
conftest.s: Assembler messages:
conftest.s:1: Error: selected processor does not support `ptrue p0.b'

Setting both CFLAGS and CXXFLAGS to "-O2 -march=native -pipe" makes
configure succeed (but of course at some point generates code that
does not actually run on the machine). Tests pass though [*].

Which makes me wonder...

> * Added libmvec vector math library support to AArch64.  It requires
>   GCC version >= 10.1.0.  It can be disabled via --disable-mathvec,
>   however that is not a supported configuration as it changes the
>   ABI.
>   The symbol names follow the AArch64 vector ABI, they are declared
>   in math.h and have to be called manually at this point.

What's the plan here for machines that do not support the SVE command set
in hardware?

Is there a fallback that preserves the ABI?
What happens if code calls the vector functions on a machine that does
not have the hardware support?
How is an analogue case handled on x86-64?

Cheers
Andreas



[*]

UNSUPPORTED: elf/tst-env-setuid
UNSUPPORTED: elf/tst-env-setuid-tunables
XPASS: elf/tst-protected1a
XPASS: elf/tst-protected1b
UNSUPPORTED: elf/tst-valgrind-smoke
UNSUPPORTED: math/test-fesetexcept-traps
UNSUPPORTED: math/test-fexcept-traps
UNSUPPORTED: math/test-nearbyint-except-2
UNSUPPORTED: misc/tst-adjtimex
UNSUPPORTED: misc/tst-clock_adjtime
UNSUPPORTED: misc/tst-ntp_adjtime
UNSUPPORTED: misc/tst-pkey
UNSUPPORTED: nptl/test-cond-printers
UNSUPPORTED: nptl/test-condattr-printers
UNSUPPORTED: nptl/test-mutex-printers
UNSUPPORTED: nptl/test-mutexattr-printers
UNSUPPORTED: nptl/test-rwlock-printers
UNSUPPORTED: nptl/test-rwlockattr-printers
UNSUPPORTED: stdlib/tst-secure-getenv
XPASS: string/tst-strerror
XPASS: string/tst-strsignal
XPASS: support/tst-support_descriptors
UNSUPPORTED: time/tst-clock_settime
UNSUPPORTED: time/tst-settimeofday
Summary of test results:
   4717 PASS
     19 UNSUPPORTED
     17 XFAIL
      5 XPASS





Am Freitag, 21. Juli 2023, 01:39:08 CEST schrieb Andreas K. Huettel via Libc-alpha:
> Question... I'm trying to configure master glibc on an aarch64 Neoverse-N1
> machine (gcc-12, binutils-2.39). This fails with
> 
> configure: WARNING: mathvec is enabled but assembler does not support SVE.
> configure: error: use a compatible toolchain or configure with --disable-mathvec (this results in incomplete ABI).
>  * ERROR: sys-libs/glibc-9999::gentoo failed (configure phase):
> 
> What's missing?
> Or is --disable-mathvec needed despite the scary message?
> 
> (Asking quickly before the weekend arrives...)
> 
> 


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]