These cannot be detected by reading the ID_AA64ISAR1_EL1 register since
their corresponding bitfields are hidden. Additionally the instructions
that these features enable are unusable from EL0.
ACLE: https://github.com/ARM-software/acle/pull/382
When #92921 added the `__arm_get_current_vg` functionality, it used the
FMV feature bits mechanism rather than the mechanism that was previously
added for SME which called `getauxval` on Linux platforms or
`__aarch64_sme_accessible` required for baremetal libraries. It is
better to always use `__aarch64_cpu_features`.
For baremetal we still need to rely on `__arm_sme_accessible` to
initialise the struct.
Features ebf16, memtag3, and rpres allow existing instructions to behave
differently depending on the value of certain control registers. FMV
does not read the content of control registers making these features
unsuitable for runtime dispatch. See the ACLE patch for more info:
https://github.com/ARM-software/acle/pull/355
…t constructor
`__init_riscv_feature_bits` takes an argument that can be
platform-specific, potentially pointing to the VDSO address of the
hwprobe system call for Linux. However, marking it as a constructor does
not guarantee that 0/NULL will always be passed to this argument, which
may result in treating an uninitialized or garbage value as a pointer to
hwprobe, leading to a crash.
The simplest solution is to introduce a small constructor function to
ensure that the platform-specific argument is set to 0/NULL.
Removes sve-bf16, sve-ebf16, and sve-i8mm since they are obsolete. One
could write target_version("sve+bf16") instead of sve-bf16 for instance.
Approved in ACLE as https://github.com/ARM-software/acle/pull/353
According to the Arm Architecture Reference Manual for A-profile
architecture you can't have one feature without having the other:
ID_AA64ZFR0_EL1.AES, bits [7:4]
> FEAT_SVE_AES implements the functionality identified by the value
0b0001.
> FEAT_SVE_PMULL128 implements the functionality identified by the value
0b0010.
> The permitted values are 0b0000 and 0b0010.
(The following was removed from the latest release of the specification,
but it appears to be a mistake that was not intended to relax the
architecture constraints. The discrepancy has been reported)
ID_AA64ISAR0_EL1.AES, bits [7:4]
> FEAT_AES implements the functionality identified by the value 0b0001.
> FEAT_PMULL implements the functionality identified by the value
0b0010.
> From Armv8, the permitted values are 0b0000 and 0b0010.
Approved in ACLE as https://github.com/ARM-software/acle/pull/352
If we split these features in the compiler (see relevant pull request
https://github.com/llvm/llvm-project/pull/109299), we would only be able
to hand-write a 'memtag2' version using inline assembly since the
compiler cannot generate the instructions that become available with
FEAT_MTE2. However these instructions only work at Exception Level 1, so
they would be unusable since FMV is a user space facility. I am
therefore unifying them.
Approved in ACLE as https://github.com/ARM-software/acle/pull/351
Base on https://github.com/riscv-non-isa/riscv-c-api-doc/pull/91 , the
marchid and mimpid are MXLEN bits wide, and kernel returned them as u64
data type. So we should use u64 data type for marchid and mimpid in
__riscv_cpu_model struct here.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
According to https://developer.arm.com/documentation/102105/latest Arm
Architecture Reference Manual for A-profile architecture: Known issues
2.206 D22789
In section C5.2.25 "SSBS, Speculative Store Bypass Safe", under the
heading 'Configurations', the text that reads:
"This register is present only when FEAT_SSBS is implemented. Otherwise,
direct accesses to SSBS are UNDEFINED."
is changed to read:
"This register is present only when FEAT_SSBS2 is implemented.
Otherwise, direct accesses to SSBS are UNDEFINED."
This suggests that it's not worth splitting FEAT_SSBS2 from FEAT_SSBS in
the compiler, since FEAT_SSBS cannot be used for predicating the MRS/MSR
instructions. Those can access PSTATE.SSBS only when FEAT_SSBS2 is
available. Moreover, there are no hardware implementations which
implement FEAT_SSBS without FEAT_SSBS2, therefore unifying these
features in the specification should not be a regression for feature
detection.
Approved in ACLE as https://github.com/ARM-software/acle/pull/350
Originally I tried spliting these features in the compiler with
https://github.com/llvm/llvm-project/pull/101712, but we decided to lump
those features in the ACLE specification (see
https://github.com/ARM-software/acle/pull/346). Since there are no
hardware implementations out there which implement ls64 without ls64_v
or ls64_accdata, this shouldn't be a regression for feature detection.
Perform the same macro expansion in the header to improve handling
the various ARM64 environments which use different CPU architecture
identification macro spellings.
When clang is used as `clang-cl`, we use MSVC style macros. The spelling
of `__aarch64__` is converted to `_M_ARM64`. Account for this
alternative spelling in the conditional check. While in the area, add a
tertiary spelling of `__arm64__` to ensure that we catch more of the
variants.
…ImplID
This patch
1. remove the vendorId from `__riscv_vendor_feature_bits`
2. Define a new structure for vendorID, ArchID and ImplID
3. Update the relate init code
This patch add `void* PlatformArgs` parameter to
`__init_riscv_feature_bits`. `PlatformArgs` allows the platform to
provide pre-computed data and access it without extra effort. For
example, Linux could pass the vDSO object to avoid an extra system call.
```
__init_riscv_feature_bits()
->
__init_riscv_feature_bits(void *PlatformArgs)
```
The spec can be found at
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74.
1. Add the new extension GroupID/Bitmask with latest hwprobe key.
2. Update the `initRISCVFeature `
3. Update `EmitRISCVCpuSupports` due to not only group0 now.
GCC-14.1.1 emit an error due to uninitialized variables
x86.c:303:17: error: ‘EAX’ may be used uninitialized
[-Werror=maybe-uninitialized]
x86.c:970:35: error: ‘MaxLevel’ may be used uninitialized
[-Werror=maybe-uninitialized]
x86.c:987:48: error: ‘MaxExtLevel’ may be used uninitialized
[-Werror=maybe-uninitialized]
It doesn't handle properly that these variables initialized indirectly
in functions that takes pointers to them
This reverts commit f1905f064451bf688577976a13000c9c47e58452.
This relands commit 19cf8deabe1124831164987f1b9bf2f806c0a875.
There were issues with the preprocessor includes that should have
excluded MSVC still including clang functions building on windows and
using intrin.h. This relanding fixes this behavior by additionally
wrapping the uses of __get_cpuid and __get_cpuid_count in _MSC_VER so
that clang in MSVC mode, which includes intrin.h, does not have any
conflicts.
Changes included:
- Adding CONSTRUCTOR_ATTRIBUTE so that the static data is setup early on
in process lifetime. This is required by gcc docs for
__builtin_cpu_supports which we hope to implement in terms of this.
- Move the length initialization outside of the #if defined(linux) block
so that the length field always reflects the size of the structures even
if non of the feature bits are non-zero.
- Change the __riscv_vendor_feature_bits.length field to match the
length of the actual structure.
Note: Copy from https://github.com/llvm/llvm-project/pull/99958
---------
Co-authored-by: Philip Reames <preames@rivosinc.com>
This addresses the spurious inclusion of (now unsupported) target
features '-3dnow' and '-3dnowa' when disabling mmx (when then caused log
output from `clang -mno-mmx`).
It should've been part of PR #96246, but was missed.
Also tweaks the warning in prfchwintrin.h to not recommend the
deprecated mm3dnow.h header.
This reverts commit f6616e99c71c15d530060346ec29c3246d7fc235.
Was causing buildbot failures on Windows. I also remember seeing a
AMDGPU buildbot failing somewhere on a warning as they have -Werror
enabled.
This reverts commit 2039e130649d8469bc85fa31ba7422d1d3739f90.
This relands commit 19cf8deabe1124831164987f1b9bf2f806c0a875.
Added some additional preprocessor directives to ensure that Host.cpp
only includes cpuid.h when being built on x86.
This patch unifies the implementation of getAMDProcessorTypeAndSubtype
between compiler-rt and LLVM.
This patch is intended to be a step towards pulling these functions out
into identical .inc files to better facilitate code sharing between LLVM
and compiler-rt.
This reverts commit 19cf8deabe1124831164987f1b9bf2f806c0a875.
This was causing quite a few buildbot failures (see the PR description).
Reverting for now while I have time to sort it out. Seems like it should
just be conditional preprocessor macros for X86 however.
This patch makes the host/feature detection in compiler-rt and LLVM use
the functions provided in cpuid.h(__get_cpuid, __get_cpuid_count)
instead of inline assembly. This simplifies the implementation and moves
any inline assembly away to a more common place.
A while ago, some similar cleanup was attempted, but this ended up
resulting in some compilation errors due to toolchain minimum version
issues (https://bugs.llvm.org/show_bug.cgi?id=30384). After the
reversion landed, there have been no attempts since then to clean up the
code, even though the minimum supported compilers now support the
relevant functions (https://godbolt.org/z/o1Mjz8ndv).
This patch refactors the AArch64 CPUFeatures enum into a separate
include file that is identical between LLVM and compiler-rt. This, along
with a test in compiler-rt to ensure that the two stay in sync.
MacOS 15.0 and iOS 18.0 added a new sysctl to fetch a bitvector of all
the hw.optional.arm.FEAT_*'s in one go. Using this has a perf advantage
over doing multiple round-trips to the kernel and back, but since it's
not present in older oses, we still need the slow fallback.
