On Wed, Aug 24, 2022 at 11:07:03AM +0700, John Naylor wrote:
> The important thing is: if we compile with __aarch64__ as a target:
> - Will the compiler emit the intended instructions from the intrinsics
> without extra flags?
My testing with GCC and Clang did not require any extra flags. GCC appears
to enable it by default for aarch64 [0]. AFAICT this is the case for Clang
as well, but that is based on the code and my testing (I couldn't find any
documentation for this).
> - Can a user on ARM64 ever get a runtime fault if the machine attempts
> to execute NEON instructions?
IIUC yes, although I'm not sure how likely it is in practice.
> "I have been able to compile for
> __aarch64__ without __ARM_NEON" doesn't really answer that question --
> what exactly did this entail?
Compiling with something like -march=armv8-a+nosimd prevents defining
__ARM_NEON. Interestingly, Clang still defines __ARM_NEON__ even when
+nosimd is specified.
> I took a quick look around at Debian code search, *BSD, Apple, and a
> few other places, and I can't find it. Then, I looked at the
> discussions around commit 5c7603c318872a42e "Add ARM64 (aarch64)
> support to s_lock.h", and the proposed patch [1] only had __aarch64__
> . When it was committed, the platform was vaporware and I suppose we
> included "__aarch64" as a prophylactic measure because no other reason
> was given. It doesn't seem to exist anywhere, so unless someone can
> demonstrate otherwise, I'm going to rip it out soon.
This is what I found, too, so +1. I've attached a patch for this.
[0] https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
