Tracking Issue for stdarch_s390x_feature_detection

[folkertdev]

Feature gate: #![feature(stdarch_s390x_feature_detection)]

This is a tracking issue for SystemZ target feature detection.

Public API

// std::arch

macro_rules! is_s390x_feature_detected { .. }

Steps / History

• Implementation: add is_s390x_feature_detected stdarch#1699
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

@rustbot label O-SystemZ

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[uweigand]

The new machines IBM z17 and IBM LinuxONE Emperor 5 were recently announced. These machines implement the arch15 level of the z/Architecture. Support for this has been added to LLVM here: llvm/llvm-project@8424bf2

This architecture level provides a number of new architecture features. LLVM supports the following:

  "miscellaneous-extensions-4"
  "vector-enhancements-3"
  "vector-packed-decimal-enhancement-3"
  "message-security-assist-extension12"
  "concurrent-functions"

It would be good to add (a subset of?) those to the list of features supported by Rust as well.

However, the Linux kernel maintainers decided to no longer provide new HWCAP bits for these features. Instead, users are encouraged to determine presence of those features via the STFLE instruction. This was done to avoid running out of HWCAP bits - new bits are now only allocated for features that require kernel support in addition to hardware support (as is currently the case for the "vector" feature).

This means the Rust implementation should be changed to primarily use STFLE to detect features, but still consult HWCAP in addition for those features that require kernel support (i.e. "vector" only right now). As an additional benefit, this would also allow properly detecting older features that do not have HWCAP bits - most notably the various "miscellaneous-extensions-N" features would be important to detect (and maybe some others).

Is this feature the proper place to discuss this, or should I open another one?
FYI @folkertdev @taiki-e @cuviper @fneddy