add more s390x target features by folkertdev · Pull Request #135630 · rust-lang/rust (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation11 Commits1 Checks6 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Closes #88937

tracking issue: #130869

The target feature names are, right now, just the llvm target feature names. These mostly line up well with the names of Facility Indications names. The linux kernel (and /proc/cpuinfo) uses shorter, more cryptic names. (e.g. "vector" is vx). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. vx for what they call vector.

There are a number of implied target features between the vector facilities (based on the Facility Indications table):

• 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode.
• 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one.
• 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one.
• 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one.
• 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one.
• 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one.
• 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one.

The remaining facilities do not have any implied target features (that we provide):

• 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode.
• 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one.
• 133 The guarded-storage facility is installed in the z/Architecture architectural mode.
• 150 The enhanced-sort facility is installed in the z/Architecture architectural mode.
• 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode.

The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM defines more target features, but I'm not sure those are useful. They can always be added later, and can already be set globally using -Ctarget-feature.

I'll also update the is_s390x_feature_supported macro (added in rust-lang/stdarch#1699, not yet on nightly, that needs an stdarch sync) to include these target features.

@Amanieu you had some reservations about the "vector" target feature name. It does appear to be the most "official" name we have. On the one hand the name is very generic, and some of the other names are rather long. For the neural-network-processing-assist even LLVM thought that was a bit much and shortened it to nnp-assist. Also for vector-packed-decimal-enhancement facility 1 the llvm naming is inconsistent. On the other hand, the cpuinfo names are very cryptic, and aren't found in the IBM documentation.

r? @Amanieu

cc @uweigand @taiki-e

rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

labels

Jan 17, 2025

This comment has been minimized.

The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM defines more target features, but I'm not sure those are useful. They can always be added later, and can already be set globally using -Ctarget-feature.

The list you've added corresponds to the list provided by /proc/cpuinfo, so I agree that's a good start. [It would be possible to check for the other features at runtime as well, but using a different mechanism (the STFLE instruction).]

Also for vector-packed-decimal-enhancement facility 1 the llvm naming is inconsistent.

Yes, unfortunately sometimes a facility gets added in one generation, and then the next generation adds a version 2 of the facility, and then the original facility is renamed as version 1 retroactively ... I didn't follow those renames in the LLVM facility names to avoid accidentally breaking existing scripts.

It would be possible to check for the other features at runtime as well

I was thinking of some of the special ones, e.g. backchain is not really a facility as far as I can tell? Similarly soft-float and unaligned-symbols. Anyway if the need comes up it's quite easy to add more.

but using a different mechanism (the STFLE instruction)

Yes, rust-lang/stdarch#1699 has some prototype code for that, but as you say for now that is not needed (plus you'd need the existing approach anyway to make sure that the STFLE instruction is supported).

Yes, unfortunately sometimes a facility gets added in one generation, and then the next generation adds a version 2 of the facility, and then the original facility is renamed as version 1 retroactively ... I didn't follow those renames in the LLVM facility names to avoid accidentally breaking existing scripts.

That is unfortunate and makes sense

It would be possible to check for the other features at runtime as well

I was thinking of some of the special ones, e.g. backchain is not really a facility as far as I can tell? Similarly soft-float and unaligned-symbols. Anyway if the need comes up it's quite easy to add more.

I see. Yes, those are not ISA facilities, but rather compiler options. These were implemented as LLVM facilities to allow setting them per-function (via attribute, or implicitly via LTO).

but using a different mechanism (the STFLE instruction)

Yes, rust-lang/stdarch#1699 has some prototype code for that, but as you say for now that is not needed (plus you'd need the existing approach anyway to make sure that the STFLE instruction is supported).

That test shouldn't really be necessary - LLVM anyway requires the Eighth Edition of the PoP as minimum level (i.e. z10 processors, which were introduced in 2010), and STFLE has been supported since the Fifth Edition.

📌 Commit 8a5bb28 has been approved by Amanieu

It is now in the queue for this repository.

bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Feb 18, 2025

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Feb 20, 2025

…r=Amanieu

add more s390x target features

Closes rust-lang#88937

tracking issue: rust-lang#130869

The target feature names are, right now, just the llvm target feature names. These mostly line up well with the names of Facility Indications names. The linux kernel (and /proc/cpuinfo) uses shorter, more cryptic names. (e.g. "vector" is vx). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. vx for what they call vector.

There are a number of implied target features between the vector facilities (based on the Facility Indications table):

• 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode.
• 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one.
• 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one.
• 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one.
• 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one.
• 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one.
• 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one.

The remaining facilities do not have any implied target features (that we provide):

• 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode.
• 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one.
• 133 The guarded-storage facility is installed in the z/Architecture architectural mode.
• 150 The enhanced-sort facility is installed in the z/Architecture architectural mode.
• 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode.

The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM defines more target features, but I'm not sure those are useful. They can always be added later, and can already be set globally using -Ctarget-feature.

I'll also update the is_s390x_feature_supported macro (added in rust-lang/stdarch#1699, not yet on nightly, that needs an stdarch sync) to include these target features.

@Amanieu you had some reservations about the "vector" target feature name. It does appear to be the most "official" name we have. On the one hand the name is very generic, and some of the other names are rather long. For the neural-network-processing-assist even LLVM thought that was a bit much and shortened it to nnp-assist. Also for vector-packed-decimal-enhancement facility 1 the llvm naming is inconsistent. On the other hand, the cpuinfo names are very cryptic, and aren't found in the IBM documentation.

r? @Amanieu

cc @uweigand @taiki-e

bors added a commit to rust-lang-ci/rust that referenced this pull request

Feb 20, 2025

Rollup of 12 pull requests

Successful merges:

• rust-lang#128080 (Specify scope in out_of_scope_macro_calls lint)
• rust-lang#135354 ([Debuginfo] Add MSVC Synthetic and Summary providers to LLDB)
• rust-lang#135630 (add more s390x target features)
• rust-lang#136089 (Reduce Box::default stack copies in debug mode)
• rust-lang#136148 (Optionally add type names to TypeIds.)
• rust-lang#137192 (Remove obsolete Windows ThinLTO+TLS workaround)
• rust-lang#137204 (Clarify MIR dialects and phases)
• rust-lang#137299 (Simplify Postorder customization.)
• rust-lang#137302 (Use a probe to avoid registering stray region obligations when re-checking drops in MIR typeck)
• rust-lang#137305 (Tweaks in and around rustc_middle)
• rust-lang#137313 (Some codegen_llvm cleanups)
• rust-lang#137333 (Use edition = "2024" in the compiler (redux))

r? @ghost @rustbot modify labels: rollup

try-job: test-various try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: i686-msvc-1 try-job: i686-msvc-2 try-job: i686-mingw-1 try-job: i686-mingw-2 try-job: i686-mingw-3 try-job: x86_64-gnu-nopt

This comment has been minimized.

The target feature names are, right now, based on the llvm target feature names. These mostly line up well with the names of Facility Inidications names. The linux kernel uses shorter, more cryptic names. (e.g. "vector" is vx). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. vx for what they call vector.

There are a number of implied target features between the vector facilities (based on the Facility Inidications table):

• 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode.
• 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one.
• 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one.
• 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one.
• 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one.
• 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one.
• 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one.

And then there are a number of facilities without any implied target features

• 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode.
• 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one.
• 133 The guarded-storage facility is installed in the z/Architecture architectural mode.
• 150 The enhanced-sort facility is installed in the z/Architecture architectural mode.
• 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode.

The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM defines more target features, but I'm not sure those are useful. They can always be added later, and can already be set globally using -Ctarget-feature.

not sure what happened there, maybe some formatting config got updated while this was open? Anyway, fixed now

@rustbot ready

We released an edition, yeah.

📌 Commit 69c7e1d has been approved by Amanieu

It is now in the queue for this repository.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Feb 20, 2025

…r=Amanieu

add more s390x target features

Closes rust-lang#88937

tracking issue: rust-lang#130869

The target feature names are, right now, just the llvm target feature names. These mostly line up well with the names of Facility Indications names. The linux kernel (and /proc/cpuinfo) uses shorter, more cryptic names. (e.g. "vector" is vx). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. vx for what they call vector.

There are a number of implied target features between the vector facilities (based on the Facility Indications table):

• 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode.
• 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one.
• 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one.
• 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one.
• 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one.
• 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one.
• 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one.

The remaining facilities do not have any implied target features (that we provide):

• 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode.
• 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one.
• 133 The guarded-storage facility is installed in the z/Architecture architectural mode.
• 150 The enhanced-sort facility is installed in the z/Architecture architectural mode.
• 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode.

The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM defines more target features, but I'm not sure those are useful. They can always be added later, and can already be set globally using -Ctarget-feature.

I'll also update the is_s390x_feature_supported macro (added in rust-lang/stdarch#1699, not yet on nightly, that needs an stdarch sync) to include these target features.

@Amanieu you had some reservations about the "vector" target feature name. It does appear to be the most "official" name we have. On the one hand the name is very generic, and some of the other names are rather long. For the neural-network-processing-assist even LLVM thought that was a bit much and shortened it to nnp-assist. Also for vector-packed-decimal-enhancement facility 1 the llvm naming is inconsistent. On the other hand, the cpuinfo names are very cryptic, and aren't found in the IBM documentation.

r? @Amanieu

cc @uweigand @taiki-e

bors added a commit to rust-lang-ci/rust that referenced this pull request

Feb 21, 2025

Rollup of 10 pull requests

Successful merges:

• rust-lang#128080 (Specify scope in out_of_scope_macro_calls lint)
• rust-lang#135630 (add more s390x target features)
• rust-lang#136089 (Reduce Box::default stack copies in debug mode)
• rust-lang#137192 (Remove obsolete Windows ThinLTO+TLS workaround)
• rust-lang#137204 (Clarify MIR dialects and phases)
• rust-lang#137299 (Simplify Postorder customization.)
• rust-lang#137302 (Use a probe to avoid registering stray region obligations when re-checking drops in MIR typeck)
• rust-lang#137305 (Tweaks in and around rustc_middle)
• rust-lang#137313 (Some codegen_llvm cleanups)
• rust-lang#137333 (Use edition = "2024" in the compiler (redux))

r? @ghost @rustbot modify labels: rollup

try-job: aarch64-gnu try-job: armhf-gnu try-job: i686-mingw-1 try-job: i686-mingw-2 try-job: i686-mingw-3 try-job: test-various try-job: x86_64-gnu-nopt try-job: x86_64-msvc-1 try-job: x86_64-msvc-2

bors added a commit to rust-lang-ci/rust that referenced this pull request

Feb 21, 2025

bors added a commit to rust-lang-ci/rust that referenced this pull request

Feb 21, 2025

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Feb 21, 2025

Rollup merge of rust-lang#135630 - folkertdev:s390x-target-features, r=Amanieu

add more s390x target features

Closes rust-lang#88937

tracking issue: rust-lang#130869

The target feature names are, right now, just the llvm target feature names. These mostly line up well with the names of Facility Indications names. The linux kernel (and /proc/cpuinfo) uses shorter, more cryptic names. (e.g. "vector" is vx). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. vx for what they call vector.

There are a number of implied target features between the vector facilities (based on the Facility Indications table):

• 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode.
• 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one.
• 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one.
• 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one.
• 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one.
• 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one.
• 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one.

The remaining facilities do not have any implied target features (that we provide):

• 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode.
• 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one.
• 133 The guarded-storage facility is installed in the z/Architecture architectural mode.
• 150 The enhanced-sort facility is installed in the z/Architecture architectural mode.
• 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode.

The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM defines more target features, but I'm not sure those are useful. They can always be added later, and can already be set globally using -Ctarget-feature.

I'll also update the is_s390x_feature_supported macro (added in rust-lang/stdarch#1699, not yet on nightly, that needs an stdarch sync) to include these target features.

@Amanieu you had some reservations about the "vector" target feature name. It does appear to be the most "official" name we have. On the one hand the name is very generic, and some of the other names are rather long. For the neural-network-processing-assist even LLVM thought that was a bit much and shortened it to nnp-assist. Also for vector-packed-decimal-enhancement facility 1 the llvm naming is inconsistent. On the other hand, the cpuinfo names are very cryptic, and aren't found in the IBM documentation.

r? @Amanieu

cc @uweigand @taiki-e

github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this pull request

Mar 11, 2025

github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this pull request

Mar 11, 2025

Labels

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.