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 codegen accordingly.
Add SME aarch64 features already supported by LLVM and Linux.
This commit adds compiler support 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
Add various aarch64 features already supported by LLVM and Linux.
The features are marked as unstable using a newly added symbol, i.e.
aarch64_unstable_target_feature.
Additionally include some comment fixes to ensure consistency of
feature names with the Arm ARM and support for architecture version
target features up to v9.5a.
This commit adds compiler support for the following features:
- FEAT_CSSC
- FEAT_ECV
- FEAT_FAMINMAX
- FEAT_FLAGM2
- FEAT_FP8
- FEAT_FP8DOT2
- FEAT_FP8DOT4
- FEAT_FP8FMA
- FEAT_FPMR
- FEAT_HBC
- FEAT_LSE128
- FEAT_LSE2
- FEAT_LUT
- FEAT_MOPS
- FEAT_LRCPC3
- FEAT_SVE_B16B16
- FEAT_SVE2p1
- FEAT_WFxT
Most modules have such a blank line, but some don't. Inserting the blank
line makes it clearer that the `//!` comments are describing the entire
module, rather than the `use` declaration(s) that immediately follows.
Before making thread_local accept statements inside the const block,
this test would fail to compile as follows:
error: no rules expected the token `let`
--> library/std/tests/thread.rs:26:13
|
26 | let value = 1;
| ^^^ no rules expected this token in macro call
|
note: while trying to match meta-variable `$init:expr`
--> library/std/src/thread/local.rs:189:69
|
189 | ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => (
| ^^^^^^^^^^
The switch_stdout_to test was broken on Windows7, as the test
infrastructure would refuse to delete the temporary test folder because
the switch-stdout-output file we redirected the stdout to was still
opened.
To fix this issue, we make switch_stdout_to return the previous handle,
and add a new switch_stdout_to call at the end of the test to return the
stdio handles to their original state. The handle the second
switch_stdout_to returns will be automatically closed, which should
allow the temporary test folder to be deleted properly.
Fix issue_15149 test for the SGX target
PR https://github.com/rust-lang/rust/pull/112390 moved tests to std. Unfortunately, this caused the `issue_15149` test to be enabled for the SGX target. This is incorrect as the SGX target does not support the `env::current_exe()` call.
This is not a library, so there's no reason for them to be `pub`.
Without doing this, compiling the test crates causes private dep
lint errors:
error: type `PathBuf` from private dependency 'std' in public interface
--> library/std/tests/common/mod.rs:26:5
|
26 | pub fn join(&self, path: &str) -> PathBuf {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `-D exported-private-dependencies` implied by `-D warnings`
error: type `Path` from private dependency 'std' in public interface
--> library/std/tests/common/mod.rs:31:5
|
31 | pub fn path(&self) -> &Path {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: could not compile `std` (test "create_dir_all_bare") due to 2 previous errors
This happens because Cargo passes `--extern 'priv:std=...` when
compiling the test crate.
I'm not sure if these warnings are desirable or not. They seem correct
in a very pedantic way (the dependency on `std` is not marked public,
since it's implicit), but also pointless (the test crate is not an API,
so who cares what it does).
Moving `create_dir_all` out of `ui-fulldeps` is complicated by the fact it sets the current directory. This means it can't be a unit test. Instead, move it to its own integration test.
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a
In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.
"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
Updated the added documentation in llvm_util.rs to note which copies of LLVM need to be inspected.
Removed avx512bf16 and avx512vp2intersect because they are unsupported before LLVM 9 with the build with external LLVM 8 being supported
Re-introduced detection testing previously removed for un-requestable features tsc and mmx
`movbe` seems to not be a run-time detectable feature on x86.
It has thus been removed from the list.
It was only commented out to ease comparison against the full list.
This PR both adds in-source documentation on what to look out for
when adding a new (X86) feature set and adds all that are detectable at run-time in Rust stable
as of 1.27.0.
This should only enable the use of the corresponding LLVM intrinsics.
Actual intrinsics need to be added separately in rust-lang/stdarch.
It also re-orders the run-time-detect test statements to be more consistent
with the actual list of intrinsics whitelisted and removes underscores not present
in the actual names (which might be mistaken as being part of the name)
