Missing support for target features on s390x

[uweigand]

There are a number of places where rust handles architecture-specific features, in particular:

• the target_feature attribute to enable/disable features when compiling parts of the code base
• the target_feature conditional compilation option to check for the presence of a feature at compile time
• the is_arch_feature_detected! macro to check for the presence of a feature at run time

All of this seems to be missing for s390x at the moment.

The LLVM back-end does support fine-grained selection of features as defined by the architecture (Principles of Operation). There is also support for run-time detection on Linux via the HWCAP mechanism and/or the /proc/cpuinfo file, however this is somewhat less fine-grained and uses slightly different naming conventions, so there may have to be some selection / name mapping here.

This is the current list of HWCAP values and the associated string in the features line in /proc/cpuinfo. Where applicable, I've also listed the corresponding LLVM feature name and architecture level where it was introduced. Some HWCAP values have no feature name, either because they're assumed to always present (LLVM doesn't support any architecture earlier than arch8), or because they refer to HW features without ISA impact.

HWCAP value          /proc           LLVM feature                          arch level
                     cpuinfo

HWCAP_S390_ESAN3     "esan3"         n/a
HWCAP_S390_ZARCH     "zarch"         n/a
HWCAP_S390_STFLE     "stfle"         n/a
HWCAP_S390_MSA       "msa"           n/a
HWCAP_S390_LDISP     "ldisp"         n/a
HWCAP_S390_EIMM      "eimm"          n/a
HWCAP_S390_DFP       "dfp"           n/a
HWCAP_S390_HPAGE     "edat"          n/a
HWCAP_S390_ETF3EH    "etf3eh"        n/a
HWCAP_S390_HIGH_GPRS "highgprs"      "high-word"                           arch9            
HWCAP_S390_TE        "te"            "transactional-execution"             arch10    
HWCAP_S390_VXRS      "vx"            "vector"                              arch11              
HWCAP_S390_VXRS_BCD  "vxd"           "vector-packed-decimal"               arch11  
HWCAP_S390_VXRS_EXT  "vxe"           "vector-enhancements-1"               arch12
HWCAP_S390_GS        "gs"            "guarded-storage"                     arch12    
HWCAP_S390_VXRS_EXT2 "vxe2"          "vector-enhancements-2"               arch13  
HWCAP_S390_VXRS_PDE  "vxp"           "vector-packed-decimal-enhancement"   arch13
HWCAP_S390_SORT      "sort"          "enhanced-sort"                       arch13            
HWCAP_S390_DFLT      "dflt"          "deflate-conversion"                  arch13           
HWCAP_S390_VXRS_PDE2 "vxp2"          "vector-packed-decimal-enhancement-2" arch14
HWCAP_S390_NNPA      "nnpa"          "nnp-assist"                          arch14                
HWCAP_S390_PCI_MIO   "pcimio"        n/a
HWCAP_S390_SIE       "sie"           n/a

As an alternative to using HWCAP, it would also be possible to detect the fine-grained facilities available in the hardware. This could be done either by parsing the facilities line in /proc/cpuinfo, or else by using the STORE FACILITY LIST EXTENDED instruction. The advantage would be that the HW facilities match 1:1 to the LLVM features. The disadvantage is that certain facilities (e.g. "transactional-execution" or "vector") require OS support in addition to HW support, e.g. to swap extended register sets during context switch. This is correctly handled by checking the HWCAP feature list, but will be missed by just checking for the HW facilities.

[folkertdev]

I'm trying to fill out this array

const IBMZ_FEATURES: &[(&str, Stability, ImpliedFeatures)] = &[
    // tidy-alphabetical-start
    ("backchain", Unstable(sym::s390x_target_feature), &[]),
    ("dflt", Unstable(sym::s390x_target_feature), &[]),
    ("gs", Unstable(sym::s390x_target_feature), &[]),
    ("highgprs", Unstable(sym::s390x_target_feature), &[]),
    ("nnpa", Unstable(sym::s390x_target_feature), &[]),
    ("sort", Unstable(sym::s390x_target_feature), &[]),
    ("te", Unstable(sym::s390x_target_feature), &[]),
    ("vx", Unstable(sym::s390x_target_feature), &[]),
    ("vxd", Unstable(sym::s390x_target_feature), &[]),
    ("vxe", Unstable(sym::s390x_target_feature), &[]),
    ("vxe2", Unstable(sym::s390x_target_feature), &[]),
    ("vxp", Unstable(sym::s390x_target_feature), &[]),
    ("vxp2", Unstable(sym::s390x_target_feature), &[]),
    // tidy-alphabetical-end
];

There is no official policy for the target feature names, but I asked around and generally the "official" name of the CPU manufacturer is used. I believe that would correspond with the /proc/cpuinfo values here. These are converted in to_llvm_features to their LLVM name.

The &[] at the end is the implied target features. I can make some guesses (e.g. vxe probably implies vx) but I'm not sure how to figure out all of the implicatons. I was hoping that LLVM might have that information, but I don't think it records that (in any case, I don't see it here). Searching for "vxe" is also not very helpful.

[uweigand]

Well, the "official" names are defined by the IBM z/Architecture Principles of Operation (https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf). See chapter "Additions to z/Architecture" starting on page 1-7 for a full list of all optional facilities. You'll note that the LLVM facility names tend to follow the official names very closely - the Linux kernel names reported in /proc/cpuinfo are actually just made up by the kernel team as they found the official names too long/unwieldy to be used for that purpose.

Two other places to point out in the Principles of Operations document:

• The "Preface" lists the evolution of the document across machine generations - you'll see subsections like "Summary of changes in the Fourteenth Edition" and so on; each will list the set of facilities added in this generation. These edition numbers match the "archNN" machine types supported by the LLVM back-end, e.g. -mcpu=arch14 will enable all facilities present in the Fourteenth Edition.
• The "Facility Indications" section in Chapter 4 "Control" (page 4-101) describes how to check at runtime which facilities are present, by checking facility indication bits set by the STORE FACILITY LIST (EXTENDED) instructions. You'll note that some bits of this list represent multiple facilities - those will always be present together as a group (or none of them).

As to dependencies between facilities, those are described at the main definition of the facility in Chapter 1, e.g. "The vector-enhancements facility 1 may be available on models implementing the vector facility for z/Architecture" or "The vector-enhancements facility 2 may be available on a model implementing the z/Architecture. The facility extends the vector-enhancements facility 1."

You can also check the Facility Indications section in Chapter 4, which has entries like:
129 - The vector facility for z/Architecture is installed in the z/Architecture architectural mode.
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.