Because stdarch has a really large number of unsafe functions with
single-line calls, `unsafe_op_in_unsafe_fn` would end up adding a lot of
noise, so for now we will allow it to migrate to 2024.
This reflects the currently available set of sysctl values as of macOS 15, on 2024-12-21. Features not (yet) exposed by `is_aarch64_feature_detected` have been left in comments to document their existence for the future.
The first rule of the `features` macro looks like this:
```
macro_rules! features {
(
@TARGET: $target:ident;
@CFG: $cfg:meta;
@MACRO_NAME: $macro_name:ident;
@MACRO_ATTRS: $(#[$macro_attrs:meta])*
$(@BIND_FEATURE_NAME: $bind_feature:tt; $feature_impl:tt; $(#[$deprecate_attr:meta];)?)*
$(@NO_RUNTIME_DETECTION: $nort_feature:tt; )*
$(@FEATURE: #[$stability_attr:meta] $feature:ident: $feature_lit:tt;
$(without cfg check: $feature_cfg_check:literal;)?
$(implied by target_features: [$($target_feature_lit:tt),*];)?
$(#[$feature_comment:meta])*)*
) => {
```
Notice all the `tt` specifiers. They are used because they are forwarded
to another macro. Only `ident`, `lifetime`, and `tt` specifiers can be
forwarded this way.
But there is an exception: `$feature_lit:tt`, which was added recently.
In theory it should cause an error like this:
```
error: no rules expected `literal` metavariable
--> /home/njn/dev/rust3/library/stdarch/crates/std_detect/src/detect/macros.rs:54:91
|
51 | / macro_rules! $macro_name {
52 | | $(
53 | | ($feature_lit) => {
54 | | $crate::detect_feature!($feature, $feature_lit $(, without cfg check: $feature_cfg_check)? ...
| | ^^^^^^^^^^^^^^^^^^ no rules expected this token in macro call
... |
88 | | };
89 | | }
| |_________- in this expansion of `is_x86_feature_detected!`
|
::: std/tests/run-time-detect.rs:145:27
|
145 | println!("tsc: {:?}", is_x86_feature_detected!("tsc"));
| ------------------------------- in this macro invocation
|
note: while trying to match keyword `true`
--> /home/njn/dev/rust3/library/stdarch/crates/std_detect/src/detect/macros.rs:12:55
|
12 | ($feature:tt, $feature_lit:tt, without cfg check: true) => {
| ^^^^
= note: captured metavariables except for `:tt`, `:ident` and `:lifetime` cannot be compared to other tokens
= note: see <https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment> for more information
```
(The URL at the end of the error has more details about this forwarding
limitation.)
In practice it doesn't cause this error. I'm not sure why, but the
existing macro implementation in rustc is far from perfect, so it's
believable that it does the wrong thing here.
Why does this matter? Because https://github.com/rust-lang/rust/pull/124141
is modifying the macro implementation, and when that PR is applied the
error *does* occur. (It's one of several cases I have found where the
existing compiler accepts code it shouldn't, but #124141 causes that
code to be rejected.)
Fortunately the fix is simple: replace the `literal` specifier with `tt`.
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the detection accordingly.
Feature dependencies for newer aarch64 fetaures differ between LLVM 18
in the Rust tree and upstream LLVM 19.
This commit updates those dependencies to reflect new LLVM upstream
changes.
Add detection for SME features supported by LLVM and the Linux Kernel.
Include commented-out hwcap fields for features supported by Linux but not by LLVM.
This commit adds feature detection for the following features:
- FEAT_SME
- FEAT_SME_F16F16
- FEAT_SME_F64F64
- FEAT_SME_F8F16
- FEAT_SME_F8F32
- FEAT_SME_FA64
- FEAT_SME_I16I64
- FEAT_SME_LUTv2
- FEAT_SME2
- FEAT_SME2p1
- FEAT_SSVE_FP8DOT2
- FEAT_SSVE_FP8DOT4
- FEAT_SSVE_FP8FMA
Linux features: https://github.com/torvalds/linux/blob/master/arch/arm64/include/uapi/asm/hwcap.h
LLVM features: llvm-project/llvm/lib/Target/AArch64/AArch64.td
Add detection for various aarch64 CPU features already supported by LLVM and Linux.
This commit adds feature detection for the following features:
- FEAT_CSSC
- FEAT_ECV
- FEAT_FAMINMAX
- FEAT_FLAGM2
- FEAT_FP8
- FEAT_FP8DOT2
- FEAT_FP8DOT4
- FEAT_FP8FMA
- FEAT_HBC
- FEAT_LSE128
- FEAT_LUT
- FEAT_MOPS
- FEAT_LRCPC3
- FEAT_SVE_B16B16
- FEAT_SVE2p1
- FEAT_WFxT
It also adds feature detection for FEAT_FPMR. It is somewhat of a
special case because FPMR only exists as a feature in LLVM 18, it has
been removed from the LLVM upstream. On that account the intention is
for it to be detectable at runtime through stdarch but not have a
corresponding compile-time Rust target feature.
Linux features: https://github.com/torvalds/linux/blob/master/arch/arm64/include/uapi/asm/hwcap.h
LLVM features: llvm-project/llvm/lib/Target/AArch64/AArch64.td
Expanded the cache size to 93 (we will need this in near future)
Fixed detection of VAES, GFNI and VPCLMULQDQ
Could not test with `cupid` because they do not support these yet
LLVM's `ssbs` and `mte` target_features represent two Arm features.
Linux's HWCAP also represents the same two features, so this is just a
documentation update.
LLVM's `ras` target_feature represents two Arm features - FEAT_RAS and FEAT_RASv1p1. There is no runtime detection for this, so this is a no-op in stdarch.
LLVM's `aes` feature covers both `FEAT_AES` and `FEAT_PMULL`, but Linux
exposes seperate feature bits. This patch makes the `aes` target_feature
correctly shortcut runtime `pmull` detection and also makes the `aes`
feature check for `pmull` at runtime to bring it in line with the
target_feature behaviour. In practice I think this makes the two runtime
features identical since the ID_AA64ISAR0_EL1 register does not allow
for PMULL without AES.
