[Support][AArch64] Detect a few more host CPU features on AArch64

[danilaml]

Summary

Add detection for lse, sve and sve2 on linux

[danilaml]

Compared to X86, there is a LOT missing (and this hasn't really been updated since ~2014), but at least add a few basic ones.

[peter.smith]

I think we need to be careful here. The extensions in that StringSwitch are for Armv8-a and hence applicable to all AArch64 CPUs. Things like sve are only available on later processors. We'll need to check to see what the intent was here before adding things. We'll also need to work out how to add tests for these, a good idea would be to see how the existing ones are tested.

Got a bit too much on at the moment to look into this in detail. May have some time next week.

[danilaml]

In D119435#3313720, @peter.smith wrote:

I think we need to be careful here. The extensions in that StringSwitch are for Armv8-a and hence applicable to all AArch64 CPUs. Things like sve are only available on later processors. We'll need to check to see what the intent was here before adding things. We'll also need to work out how to add tests for these, a good idea would be to see how the existing ones are tested.

Got a bit too much on at the moment to look into this in detail. May have some time next week.

Hm, I'm not sure what you mean by "be careful here". This code just matches the `/proc/cpuinfo/ output to LLVM features. The only "hard" part here is figuring which LLVM feature corresponds to cpuinfo one (that's why I've added only a small subset), but for something like sve/sve2 it's obvious. It also wouldn't be reported on a CPU that doesn't support it.
I've looked at the feature descriptions here: https://github.com/google/cpu_features/blob/main/include/cpuinfo_aarch64.h

I don' think this is tested anywhere (all recent updates to this code were done without adding tests) and if it's possible to test it without some complicated setup (launching llvm in qemu?).

[peter.smith]

You'll have to forgive me, I'm coming at this without a lot of context other than what is supported on what Arm architecture, and I didn't have time to reverse engineer it from the code. Thanks for the link, that makes it look like this is related to something like parsing proc/cpuinfo and nowhere else.

If that is the case, would it be possible to update the description with a bit more context, including the link you posted to the available values. Many of the reviewers here won't have the linux context so it can help reviewers if they know what they need to check for.

If this is indeed linux related, may I suggest adding nickdesaulniers as a reviewer. He has been involved in clang built linux project and may know more people that can help from the linux kernel side. If we are going to add more features it would be good to think about what we need to support in total and how to get there across one or more patches.

For testing, given that this is something from the environment I think it would require a unit-test if done on the LLVM side. Making one of those would be good, but quite a bit of work, would be good to put a comment in the description for the benefit of other reviewers.

[danilaml]

In D119435#3313897, @peter.smith wrote:

You'll have to forgive me, I'm coming at this without a lot of context other than what is supported on what Arm architecture, and I didn't have time to reverse engineer it from the code. Thanks for the link, that makes it look like this is related to something like parsing proc/cpuinfo and nowhere else.

If that is the case, would it be possible to update the description with a bit more context, including the link you posted to the available values. Many of the reviewers here won't have the linux context so it can help reviewers if they know what they need to check for.

If this is indeed linux related, may I suggest adding nickdesaulniers as a reviewer. He has been involved in clang built linux project and may know more people that can help from the linux kernel side. If we are going to add more features it would be good to think about what we need to support in total and how to get there across one or more patches.

For testing, given that this is something from the environment I think it would require a unit-test if done on the LLVM side. Making one of those would be good, but quite a bit of work, would be good to put a comment in the description for the benefit of other reviewers.

Yes, Arm implementation of this function on linux appears to just parse /proc/cpuinfo (see Line 1681 and below), compared to x86 one that inspects CPUID bits (I assume because something similar is not possible in userspace on Arm? Might be wrong here, but Win implementation goes with the similar route).

The link is just something I've used as a neat human-readable description of what each capability actually means collected in one place as linux kernel doc only refers to the bit it checks (requiring another lookup in Arm reference): https://www.kernel.org/doc/html/latest/arm64/elf_hwcaps.html

[nickdesaulniers]

llvm/lib/Support/Host.cpp

1709

The Features line of the cpus in my pixel 6 pro have atomics (but not sve or sve2). (I don't have an aarch64 host machine for development, yet)

Example:

Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp

to prevent this from getting out of date again, I wonder if we should assert in the default case (and add the rest)?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/include/uapi/asm/hwcap.h seems to describe these.

[tschuett]

https://github.com/torvalds/linux/blob/master/Documentation/arm64/cpu-feature-registers.rst
Is similar to how Intel is doing feature detection.

[danilaml]

In D119435#3316044, @tschuett wrote:

https://github.com/torvalds/linux/blob/master/Documentation/arm64/cpu-feature-registers.rst
Is similar to how Intel is doing feature detection.

Just as I suspected, not accessible from userspace:

Access to these system registers is restricted from EL0 and there is no reliable way for an application to extract this information to make better decisions at runtime.

llvm/lib/Support/Host.cpp

1709

What do you mean by "assert in the default case"? Assert if we encounter unknown feature? Feels too restrictive. I don't think there is a 1-to-1 between all HWCAP stuff and LLVM features (although I might be wrong), i.e. is uscat == LSE2 or something else?

[tschuett]

This file describes the ABI for exporting the AArch64 CPU ID/feature registers to userspace. The availability of this ABI is advertised via the HWCAP_CPUID in HWCAPs.

and

https://github.com/rust-lang/rust/blob/master/src/tools/rustfmt/tests/source/cfg_if/detect/os/aarch64.rs

So it should be possible from user space.

https://reviews.llvm.org/D92619

[danilaml]

In D119435#3316830, @tschuett wrote:

This file describes the ABI for exporting the AArch64 CPU ID/feature registers to userspace. The availability of this ABI is advertised via the HWCAP_CPUID in HWCAPs.

and

https://github.com/rust-lang/rust/blob/master/src/tools/rustfmt/tests/source/cfg_if/detect/os/aarch64.rs

So it should be possible from user space.

https://reviews.llvm.org/D92619

Good, this means there could be some less OS-specific way to get the features, similarly to x86, however it appears to not be guaranteed, so cpuinfo fallback will still need to exist.

[danilaml]

@peter.smith @nickdesaulniers What needs to be done to move forward with this? Do I need to add more procinfo<>feature mappings? Implement a new way to get features entirely?

[nickdesaulniers]

Sorry for the delay; I was on vacation last week. LGTM

llvm/lib/Support/Host.cpp

 #endif
 
   for (unsigned I = 0, E = CPUFeatures.size(); I != E; ++I) {
     StringRef LLVMFeatureStr = StringSwitch<StringRef>(CPUFeatures[I])
 #if defined(__aarch64__)
                                    .Case("asimd", "neon")
                                    .Case("fp", "fp-armv8")
                                    .Case("crc32", "crc")
+                                   .Case("atomics", "lse")
+                                   .Case("sve", "sve")
+                                   .Case("sve2", "sve2")
 #else
                                    .Case("half", "fp16")
                                    .Case("neon", "neon")
                                    .Case("vfpv3", "vfp3")
                                    .Case("vfpv3d16", "d16")
                                    .Case("vfpv4", "vfp4")
                                    .Case("idiva", "hwdiv-arm")
                                    .Case("idivt", "hwdiv")