Rollup merge of #162325 - RalfJung:aix-abi, r=beetrees

powerpc64-ibm-aix: fix cfg(target_abi) value

Our powerpc64-ibm-aix target currently sets `cfg_abi` to "vec-extabi", which means that programs compiled for this target *think* they use that ABI. Even our inline asm logic trusts this field. But that's a lie, we're actually using the default ABI since we are never setting `EnableAIXExtendedAltivecABI` on the LLVM side. We should fix that discrepancy.

Between changing how we generate the code, and changing the label we put into `cfg_abi`, the latter is the less risky change. So let's do that.

This has been tried before in #153830. We then decided to wait a bit while the target maintainers investigate whether they want to change the ABI or not. I think we have waited long enough. The last comment from them that I found is [this one](#153876 (comment)) which says "I'd conclude the extend vector ABI should be disabled for now"; there have been further questions but no further communication. We can always still change the ABI in the future, but for now let's fix the obvious bug where the ABI we report in `cfg_abi` does not match the actual ABI we are compiling for.

Cc @Gelbpunkt @daltenty @gilamn5tr @amy-kwan @taiki-e

Author: JonathanBrouwer

compiler/rustc_target/src/asm/powerpc.rs

@@ -4,7 +4,7 @@ use rustc_data_structures::fx::FxIndexSet;
 use rustc_span::Symbol;
 
 use super::{InlineAsmArch, InlineAsmType, ModifierInfo};
-use crate::spec::{CfgAbi, RelocModel, RustcAbi, Target};
+use crate::spec::{RelocModel, RustcAbi, Target};
 
 def_reg_class! {
     PowerPC PowerPCInlineAsmRegClass {
@@ -107,11 +107,8 @@ fn reserved_v20to31(
     _is_clobber: bool,
 ) -> Result<(), &'static str> {
     if target.is_like_aix {
-        match &target.options.cfg_abi {
-            CfgAbi::VecDefault => Err("v20-v31 (vs52-vs63) are reserved on vec-default ABI"),
-            CfgAbi::VecExtAbi => Ok(()),
-            abi => unreachable!("unrecognized AIX ABI: {abi}"),
-        }
+        // We do not support the vec-extabi at the moment.
+        Err("v20-v31 (vs52-vs63) are reserved on vec-default ABI")
     } else {
         Ok(())
     }

compiler/rustc_target/src/spec/base/aix.rs

@@ -7,7 +7,13 @@ use crate::spec::{
 
 pub(crate) fn opts() -> TargetOptions {
     TargetOptions {
-        cfg_abi: CfgAbi::VecExtAbi,
+        // It makes no sense to set "vec-extabi" here without also actually configuring LLVM to use
+        // that ABI. Since https://github.com/llvm/llvm-project/pull/221670 this probably just needs
+        // `llvm_abiname` to be set properly. If you are doing that, make sure to also:
+        // - adjust the logic in `reserved_v20to31` in `asm/powerpc.rs` to allow the extra registers
+        //   to be used depending on `llvm_abiname`.
+        // - adjust the logic in `spec/consistency.rs` to correlate `llvm_abiname` with `cfg_abi`.
+        cfg_abi: CfgAbi::VecDefault,
         code_model: Some(CodeModel::Large),
         cpu: "pwr7".into(),
         os: Os::Aix,

compiler/rustc_target/src/spec/consistency.rs

@@ -484,7 +484,7 @@ impl Target {
                     // (vec-default vs vec-ext).
                     check_matches!(
                         (&self.llvm_abiname, &self.cfg_abi),
-                        (LlvmAbi::Unspecified, CfgAbi::VecDefault | CfgAbi::VecExtAbi),
+                        (LlvmAbi::Unspecified, CfgAbi::VecDefault),
                         "invalid PowerPC64 AIX ABI name and `cfg(target_abi)` combination:\n\
                         ABI name: {}\n\
                         cfg(target_abi): {}",

compiler/rustc_target/src/spec/mod.rs

@@ -1950,7 +1950,6 @@ crate::target_spec_enum! {
         Spe = "spe",
         Uwp = "uwp",
         VecDefault = "vec-default",
-        VecExtAbi = "vec-extabi",
         X32 = "x32",
         V8Plus = "v8plus",
         Unspecified = "",