s390x: z17 target feature detection #1832

folkertdev · 2025-06-12T16:01:35Z

I didn't add feature detection yet in #1826.

The implementation follows the information in rust-lang/rust#135413 (comment), in particular that HWCAP is used to check for the vector feature because it needs kernel support, and stfle is used for the other features because they only need hardware support.

cc @uweigand @taiki-e

rustbot · 2025-06-12T16:01:40Z

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

crates/std_detect/src/detect/os/linux/s390x.rs

taiki-e · 2025-06-12T17:25:31Z

crates/std_detect/src/detect/os/linux/s390x.rs

+/// These values are part of the platform-specific [asm/elf.h][kernel], and are a selection of the
+/// fields found in the [Facility Indications].
+///
+/// [Facility Indications]: https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf#page=63


Where did you get the information about the facility bits that will be added in z17? (It is not included in the documentation at this link.)

I can confirm that the z17 facility bit values are correct. The new version of the Principles of Operation including z17 features will be released shortly after the general availability of the new machine (which is next week).

The new PoP is now available here: https://www.ibm.com/docs/en/module_1678991624569/pdf/SA22-7832-14.pdf

uweigand · 2025-06-14T00:10:08Z

crates/std_detect/src/detect/os/linux/s390x.rs

+        enable_if_set(133, Feature::guarded_storage);
+        enable_if_set(150, Feature::enhanced_sort);
+        enable_if_set(151, Feature::deflate_conversion);
+        // added in z17


Do we need this comment? If so, should we add this information also for the vector-related facilities, and also specific machine information for pre-z17 machines?

nah, this list doesn't really have structure to it, but it should be OK given the official docs.

uweigand · 2025-06-14T00:11:20Z

crates/std_detect/src/detect/os/linux/s390x.rs

+        enable_if_set(151, Feature::deflate_conversion);
+        // added in z17
+        enable_if_set(84, Feature::miscellaneous_extensions_4);
+        enable_if_set(86, Feature::message_security_assist_extension12);


We should really include all currently defined features here. What I see missing is the older variants of miscellaneous_extensions and messact_security_assist_extension. These all have defined facility bits.

We can only add features here when they are also recognized by the compiler. I'll add them there, but that does not need to block this PR I think

ah, I forgot that we did already add these to the compiler. Now they're in this PR too.

Thanks! Looks good to me now.

folkertdev · 2025-06-19T14:45:45Z

the build broke because a feature got stabilized:

    Updating crates.io index
   Compiling core_arch v0.1.5 (/Users/runner/work/stdarch/stdarch/crates/core_arch)
error: the feature `generic_arg_infer` has been stable since 1.89.0-nightly and no longer requires an attribute to enable
  --> crates/core_arch/src/lib.rs:34:5
   |
34 |     generic_arg_infer,
   |     ^^^^^^^^^^^^^^^^^
   |
   = note: `-D stable-features` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(stable_features)]`

error: could not compile `core_arch` (lib) due to 1 previous error

I'll add a commit to remove that line

… r=Amanieu Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro closes rust-lang#145649 closes rust-lang#135413 cc: rust-lang#130869 reference PR: rust-lang/reference#1972 # Stabilization report ## Summary This PR stabilizes the following s390x target features: - `vector` - `vector-enhancements-1` - `vector-enhancements-2` - `vector-enhancements-3` - `vector-packed-decimal` - `vector-packed-decimal-enhancement` - `vector-packed-decimal-enhancement-2` - `vector-packed-decimal-enhancement-3` - `nnp-assist` - `miscellaneous-extensions-2` - `miscellaneous-extensions-3` - `miscellaneous-extensions-4` Additionally, it stabilizes the `std::arch::is_s390x_feature_detected!` macro itself and stably accepts the target features listed above. ## Tests & ABI details Only the `vector` target feature changes the ABI, much like e.g. `avx2` it will, depending on the ABI, pass vector types in vector registers. This behavior is tested extensively: - [tests/assembly-llvm/s390x-vector-abi.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/codegen-llvm/s390x-simd.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/ui/abi/simd-abi-checks-s390x.rs ](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs ) The remaining features don't influence the ABI, they only influence instruction selection. In stdarch we test that the expected instructions are in fact generated when the target feature is enabled. ## Implementation history For `is_s390x_feature_detected!`: - rust-lang/stdarch#1699 - rust-lang#138275 - rust-lang/stdarch#1720 - rust-lang/stdarch#1832 For `vector` and friends - rust-lang#127506 - rust-lang#135630 - rust-lang#141250 ## Unresolved questions There is a fixme in [tests/ui/abi/simd-abi-checks-s390x.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs): ``` // FIXME: +soft-float itself doesn't set -vector //`@[z13_soft_float]` compile-flags: --target s390x-unknown-linux-gnu -C target-cpu=z13 -C target-feature=-vector,+soft-float //`@[z13_soft_float]` needs-llvm-components: systemz ``` I'm not sure whether that blocks stabilization? --- The implementation first extracts the listed target features into their own `s390x_target_feature_vector` rust feature, and then stabilizes that. best reviewed commit-by-commit r? `@Amanieu` cc `@uweigand` `@taiki-e`

… r=Amanieu Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro closes rust-lang#145649 closes rust-lang#135413 cc: rust-lang#130869 reference PR: rust-lang/reference#1972 # Stabilization report ## Summary This PR stabilizes the following s390x target features: - `vector` - `vector-enhancements-1` - `vector-enhancements-2` - `vector-enhancements-3` - `vector-packed-decimal` - `vector-packed-decimal-enhancement` - `vector-packed-decimal-enhancement-2` - `vector-packed-decimal-enhancement-3` - `nnp-assist` - `miscellaneous-extensions-2` - `miscellaneous-extensions-3` - `miscellaneous-extensions-4` Additionally, it stabilizes the `std::arch::is_s390x_feature_detected!` macro itself and stably accepts the target features listed above. ## Tests & ABI details Only the `vector` target feature changes the ABI, much like e.g. `avx2` it will, depending on the ABI, pass vector types in vector registers. This behavior is tested extensively: - [tests/assembly-llvm/s390x-vector-abi.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/codegen-llvm/s390x-simd.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/ui/abi/simd-abi-checks-s390x.rs ](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs ) The remaining features don't influence the ABI, they only influence instruction selection. In stdarch we test that the expected instructions are in fact generated when the target feature is enabled. ## Implementation history For `is_s390x_feature_detected!`: - rust-lang/stdarch#1699 - rust-lang#138275 - rust-lang/stdarch#1720 - rust-lang/stdarch#1832 For `vector` and friends - rust-lang#127506 - rust-lang#135630 - rust-lang#141250 ## Unresolved questions There is a fixme in [tests/ui/abi/simd-abi-checks-s390x.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs): ``` // FIXME: +soft-float itself doesn't set -vector //``@[z13_soft_float]`` compile-flags: --target s390x-unknown-linux-gnu -C target-cpu=z13 -C target-feature=-vector,+soft-float //``@[z13_soft_float]`` needs-llvm-components: systemz ``` I'm not sure whether that blocks stabilization? --- The implementation first extracts the listed target features into their own `s390x_target_feature_vector` rust feature, and then stabilizes that. best reviewed commit-by-commit r? ``@Amanieu`` cc ``@uweigand`` ``@taiki-e``

Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro closes #145649 closes #135413 cc: #130869 reference PR: rust-lang/reference#1972 # Stabilization report ## Summary This PR stabilizes the following s390x target features: - `vector` - `vector-enhancements-1` - `vector-enhancements-2` - `vector-enhancements-3` - `vector-packed-decimal` - `vector-packed-decimal-enhancement` - `vector-packed-decimal-enhancement-2` - `vector-packed-decimal-enhancement-3` - `nnp-assist` - `miscellaneous-extensions-2` - `miscellaneous-extensions-3` - `miscellaneous-extensions-4` Additionally, it stabilizes the `std::arch::is_s390x_feature_detected!` macro itself and stably accepts the target features listed above. ## Tests & ABI details Only the `vector` target feature changes the ABI, much like e.g. `avx2` it will, depending on the ABI, pass vector types in vector registers. This behavior is tested extensively: - [tests/assembly-llvm/s390x-vector-abi.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/codegen-llvm/s390x-simd.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/ui/abi/simd-abi-checks-s390x.rs ](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs ) The remaining features don't influence the ABI, they only influence instruction selection. In stdarch we test that the expected instructions are in fact generated when the target feature is enabled. ## Implementation history For `is_s390x_feature_detected!`: - rust-lang/stdarch#1699 - #138275 - rust-lang/stdarch#1720 - rust-lang/stdarch#1832 For `vector` and friends - #127506 - #135630 - #141250 ## Unresolved questions There is a fixme in [tests/ui/abi/simd-abi-checks-s390x.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs): ``` // FIXME: +soft-float itself doesn't set -vector //`@[z13_soft_float]` compile-flags: --target s390x-unknown-linux-gnu -C target-cpu=z13 -C target-feature=-vector,+soft-float //`@[z13_soft_float]` needs-llvm-components: systemz ``` I'm not sure whether that blocks stabilization? --- The implementation first extracts the listed target features into their own `s390x_target_feature_vector` rust feature, and then stabilizes that. best reviewed commit-by-commit r? `@Amanieu` cc `@uweigand` `@taiki-e`

… r=Amanieu Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro closes rust-lang#145649 closes rust-lang#135413 cc: rust-lang#130869 reference PR: rust-lang/reference#1972 # Stabilization report ## Summary This PR stabilizes the following s390x target features: - `vector` - `vector-enhancements-1` - `vector-enhancements-2` - `vector-enhancements-3` - `vector-packed-decimal` - `vector-packed-decimal-enhancement` - `vector-packed-decimal-enhancement-2` - `vector-packed-decimal-enhancement-3` - `nnp-assist` - `miscellaneous-extensions-2` - `miscellaneous-extensions-3` - `miscellaneous-extensions-4` Additionally, it stabilizes the `std::arch::is_s390x_feature_detected!` macro itself and stably accepts the target features listed above. ## Tests & ABI details Only the `vector` target feature changes the ABI, much like e.g. `avx2` it will, depending on the ABI, pass vector types in vector registers. This behavior is tested extensively: - [tests/assembly-llvm/s390x-vector-abi.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/codegen-llvm/s390x-simd.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/ui/abi/simd-abi-checks-s390x.rs ](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs ) The remaining features don't influence the ABI, they only influence instruction selection. In stdarch we test that the expected instructions are in fact generated when the target feature is enabled. ## Implementation history For `is_s390x_feature_detected!`: - rust-lang/stdarch#1699 - rust-lang#138275 - rust-lang/stdarch#1720 - rust-lang/stdarch#1832 For `vector` and friends - rust-lang#127506 - rust-lang#135630 - rust-lang#141250 ## Unresolved questions There is a fixme in [tests/ui/abi/simd-abi-checks-s390x.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs): ``` // FIXME: +soft-float itself doesn't set -vector //`@[z13_soft_float]` compile-flags: --target s390x-unknown-linux-gnu -C target-cpu=z13 -C target-feature=-vector,+soft-float //`@[z13_soft_float]` needs-llvm-components: systemz ``` I'm not sure whether that blocks stabilization? --- The implementation first extracts the listed target features into their own `s390x_target_feature_vector` rust feature, and then stabilizes that. best reviewed commit-by-commit r? `@Amanieu` cc `@uweigand` `@taiki-e`

Rollup merge of #145656 - folkertdev:stabilize-s390x-vector, r=Amanieu Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro closes #145649 closes #135413 cc: #130869 reference PR: rust-lang/reference#1972 # Stabilization report ## Summary This PR stabilizes the following s390x target features: - `vector` - `vector-enhancements-1` - `vector-enhancements-2` - `vector-enhancements-3` - `vector-packed-decimal` - `vector-packed-decimal-enhancement` - `vector-packed-decimal-enhancement-2` - `vector-packed-decimal-enhancement-3` - `nnp-assist` - `miscellaneous-extensions-2` - `miscellaneous-extensions-3` - `miscellaneous-extensions-4` Additionally, it stabilizes the `std::arch::is_s390x_feature_detected!` macro itself and stably accepts the target features listed above. ## Tests & ABI details Only the `vector` target feature changes the ABI, much like e.g. `avx2` it will, depending on the ABI, pass vector types in vector registers. This behavior is tested extensively: - [tests/assembly-llvm/s390x-vector-abi.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/codegen-llvm/s390x-simd.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs) - [tests/ui/abi/simd-abi-checks-s390x.rs ](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs ) The remaining features don't influence the ABI, they only influence instruction selection. In stdarch we test that the expected instructions are in fact generated when the target feature is enabled. ## Implementation history For `is_s390x_feature_detected!`: - rust-lang/stdarch#1699 - #138275 - rust-lang/stdarch#1720 - rust-lang/stdarch#1832 For `vector` and friends - #127506 - #135630 - #141250 ## Unresolved questions There is a fixme in [tests/ui/abi/simd-abi-checks-s390x.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs): ``` // FIXME: +soft-float itself doesn't set -vector //`@[z13_soft_float]` compile-flags: --target s390x-unknown-linux-gnu -C target-cpu=z13 -C target-feature=-vector,+soft-float //`@[z13_soft_float]` needs-llvm-components: systemz ``` I'm not sure whether that blocks stabilization? --- The implementation first extracts the listed target features into their own `s390x_target_feature_vector` rust feature, and then stabilizes that. best reviewed commit-by-commit r? `@Amanieu` cc `@uweigand` `@taiki-e`

rustbot assigned Amanieu Jun 12, 2025

taiki-e reviewed Jun 12, 2025

View reviewed changes

crates/std_detect/src/detect/os/linux/s390x.rs Outdated Show resolved Hide resolved

folkertdev force-pushed the s390x-z17-target-feature-detection branch from d968db9 to 7bf8a59 Compare June 12, 2025 17:20

taiki-e reviewed Jun 12, 2025

View reviewed changes

folkertdev force-pushed the s390x-z17-target-feature-detection branch from 7bf8a59 to 3809ead Compare June 12, 2025 17:31

uweigand reviewed Jun 14, 2025

View reviewed changes

folkertdev force-pushed the s390x-z17-target-feature-detection branch 3 times, most recently from 9ab93dc to 1ddb86f Compare June 18, 2025 15:35

Amanieu added this pull request to the merge queue Jun 19, 2025

github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jun 19, 2025

folkertdev added 2 commits June 19, 2025 16:49

the generic_arg_infer feature is now stable on nightly

68fbb49

s390x: add feature detection for the z17 target features

dac9666

folkertdev force-pushed the s390x-z17-target-feature-detection branch from 1ddb86f to dac9666 Compare June 19, 2025 14:49

Amanieu enabled auto-merge June 19, 2025 14:50

Amanieu added this pull request to the merge queue Jun 19, 2025

Merged via the queue into rust-lang:master with commit 5a7342f Jun 19, 2025
62 checks passed

folkertdev mentioned this pull request Aug 20, 2025

Stabilize s390x vector target feature and is_s390x_feature_detected! macro rust-lang/rust#145656

Merged

s390x: z17 target feature detection #1832

s390x: z17 target feature detection #1832

Uh oh!

Conversation

folkertdev commented Jun 12, 2025

Uh oh!

rustbot commented Jun 12, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

folkertdev commented Jun 19, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants