[AIX][Frontend] C++ ABI customizations for AIX boilerplate

[Xiangling_L]

Summary

This PR enables XL C++ ABI in frontend AST to IR codegen. And it is driven by static init work. The current kind in Clang by default is Generic Itanium, which has different behavior on static init with XLClang on AIX.

More context where the static init will be going refers to the patch: D74166.

[daltenty]

clang/include/clang/Basic/TargetCXXABI.h

116

Why the underscore in the name? This is a bit inconsistent with both the LLVM naming convention here and the name as it appears in other sources.

[stevewan]

clang/lib/CodeGen/ItaniumCXXABI.cpp

520

The class name here is inconsistent with how our ABI kind was called previously, as David pointed out. Maybe rename the ABI kind XLClang?

[Xiangling_L]

clang/include/clang/Basic/TargetCXXABI.h

116

There are various AIX ABI. So to distinguish the one we are implementing, we choose XL and Clang as two parts of the abi name.
XL - not g++;
Clang - it's a ABI implemented in Clang;

And also XLClang is misleading because it represents our AIX XL C/C++ compiler itself externally.

clang/lib/CodeGen/ItaniumCXXABI.cpp

520

I understand you concerns, and please see my replies above.

[sfertile]

clang/include/clang/Basic/TargetCXXABI.h

116

So do we need the 'Clang' part in the name? For example the ABI below is not Microsoft_Clang. Or is the _Clang differentiating between multiple XL ABIs?

[cebowleratibm]

Looks fine, but we need to settle on the name for the ABI. My preference would be "XLC++11", or perhaps "XLCXX11" (I propose the latter because of the common reference CXXABI.)

clang/include/clang/Basic/TargetCXXABI.h

116

I suspect the concern is that "XL" ABI is ambiguious between legacy xlC and xlclang++. The two differ at the C++11 language level so perhaps it makes sense to have "XLC++11"? (and theoretically just "XL" if we ever decide xlC)

clang/lib/CodeGen/ItaniumCXXABI.cpp

4428

Omit "fully". Fix the name XL_Clang when we've settled on a name.

clang/test/CodeGen/static-init.cpp

10

Nit: formatting.

The test is fine but I'd usually write this test even more briefly:
struct S { ~S(); } s;

[Xiangling_L]

Adjust ABI name to XL;
Simplify the testcase;

[sfertile]

clang/lib/CodeGen/ItaniumCXXABI.cpp

520

Here would be a good place to add a comment to indicate that XL has several C++ ABIs, but this represents the one used in 'xlClang++'.

[Xiangling_L]

clang/lib/CodeGen/ItaniumCXXABI.cpp

520

You mean we have legacy XLC and XLClang++ ABI? But for static init, they have same implementation. So it's not a must to point it out.

And also AFAIK, static init is the only thing we will differ from Generic Itanium ABI in the frontend, so basically it's the only thing we will add in this ABI.

I am okay with either way with a little concern that legacy XLC user may wonder is there any difference of static init implementation between XLC and XLClang++ ABI if we add the comment.

[sfertile]

clang/lib/CodeGen/ItaniumCXXABI.cpp

520

Sorry, I had a matching comment on the 'XL' enum, but I must have deleted it accidentally before submitting. I said I agreed with using just 'XL' since there is only one XL C++ ABI implemented in Clang we don't have to worry about differentiating between the 'legacy' XL and the C++11 XL ABIs. If you did want to clarify then adding a comment here would be the only thing I suggest.

[Xiangling_L]

clang/lib/CodeGen/ItaniumCXXABI.cpp

520

I see. Thank you for your clarification.

[Xiangling_L]

ping.

[cebowleratibm]

From my perspective, the only issue holding this up is settling on the name. I'd like to hammer that out and get this committed.

clang/include/clang/Basic/TargetCXXABI.h

116

Another suggestion: "IBMXL" or "IBMXLC++11"

[Xiangling_L]

In D74015#1880847, @cebowleratibm wrote:

From my perspective, the only issue holding this up is settling on the name. I'd like to hammer that out and get this committed.

It looks everyone agrees on XL so far. As for your other suggestion IBMXL, if your intention is to clarify this ABI is IBM product specific, I think a good practice we can do is to leave a comment when we defined it as Microsoft does.

[sfertile]

Patch LGTM as far a formatting/naming/testing etc. C++ specifics is outside my wheelhouse though, so I can't confirm things like the tail padding rules are correct for AIX. Because of that I'm not comfortable being the one to accept the patch.

[cebowleratibm]

In D74015#1882933, @sfertile wrote:

Patch LGTM as far a formatting/naming/testing etc. C++ specifics is outside my wheelhouse though, so I can't confirm things like the tail padding rules are correct for AIX. Because of that I'm not comfortable being the one to accept the patch.

I checked the IBM xlclang source and can confirm the implementation of getTailPaddingUseRules is consistent with the proposed patch. Sean, does that address your concern?

The only change I would like to see is an update to the "XL" enumerator comment to be more descriptive of what the "XL" ABI is.

clang/include/clang/Basic/TargetCXXABI.h

116

To summarize some off phabricator discussion: we reached consensus on "XL". It was not felt that "IBM" needs to be in the name and that a comment by the enumerator definition is sufficient.

Note that "XL" refers to ABI compatibiliity with the AIX xlclang compiler and not xlC. If we need xlC compatibility that would be yet another ABI to add at another time.

The comment should be updated to provide more background on what the "XL" ABI is.

[Xiangling_L]

Update the comment about ABI description;

[sfertile]

LGTM.

[jasonliu]

Just kindly reminder that you might want to update the Summary in the commit message to reflect the new name we picked.

clang/include/clang/Basic/TargetCXXABI.h

enum Kind {
     WebAssembly,
 
     /// The Fuchsia ABI is a modified version of the Itanium ABI.
     ///
     /// The relevant changes from the Itanium ABI are:
     ///   - constructors and destructors return 'this', as in ARM.
     Fuchsia,
 
+    /// The XL ABI is the ABI used by IBM xlclang compiler and is a modified
+    /// version of the Itanium ABI.
+    ///
+    /// The relevant changes from the Itanium ABI are:
+    ///   - static initialization is adjusted to use sinit and sterm functions;
+    XL,
+
     /// The Microsoft ABI is the ABI used by Microsoft Visual Studio (and
     /// compatible compilers).
     ///
     /// FIXME: should this be split into Win32 and Win64 variants?
     ///
     /// Only scattered and incomplete official documentation exists.
     Microsoft
   };
bool isItaniumFamily() const {
     case GenericAArch64:
     case GenericItanium:
     case GenericARM:
     case iOS:
     case iOS64:
     case WatchOS:
     case GenericMIPS:
     case WebAssembly:
+    case XL:
       return true;
 
     case Microsoft:
       return false;
     }
     llvm_unreachable("bad ABI kind");
   }
 
   /// Is this ABI an MSVC-compatible ABI?
   bool isMicrosoft() const {
     switch (getKind()) {
     case Fuchsia:
     case GenericAArch64:
     case GenericItanium:
     case GenericARM:
     case iOS:
     case iOS64:
     case WatchOS:
     case GenericMIPS:
     case WebAssembly:
+    case XL:
       return false;
 
     case Microsoft:
       return true;
     }
     llvm_unreachable("bad ABI kind");
   }
 
case GenericMIPS:
       // TODO: ARM-style pointers to member functions put the discriminator in
       //       the this adjustment, so they don't require functions to have any
       //       special alignment and could therefore also return false.
     case GenericItanium:
     case iOS:
     case iOS64:
     case WatchOS:
     case Microsoft:
+    case XL:
       return true;
     }
     llvm_unreachable("bad ABI kind");
   }
 
   /// Are arguments to a call destroyed left to right in the callee?
   /// This is a fundamental language change, since it implies that objects
   /// passed by value do *not* live to the end of the full expression.
bool canKeyFunctionBeInline() const {
     case WatchOS:
       return false;
 
     case GenericAArch64:
     case GenericItanium:
     case iOS:   // old iOS compilers did not follow this rule
     case Microsoft:
     case GenericMIPS:
+    case XL:
       return true;
     }
     llvm_unreachable("bad ABI kind");
   }
 
   /// When is record layout allowed to allocate objects in the tail
   /// padding of a base class?
   ///
TailPaddingUseRules getTailPaddingUseRules() const {
     // To preserve binary compatibility, the generic Itanium ABI has
     // permanently locked the definition of POD to the rules of C++ TR1,
     // and that trickles down to derived ABIs.
     case GenericItanium:
     case GenericAArch64:
     case GenericARM:
     case iOS:
     case GenericMIPS:
+    case XL:
       return UseTailPaddingUnlessPOD03;
 
     // iOS on ARM64 and WebAssembly use the C++11 POD rules.  They do not honor
     // the Itanium exception about classes with over-large bitfields.
     case Fuchsia:
     case iOS64:
     case WebAssembly:
     case WatchOS:

clang/lib/AST/ASTContext.cpp

CXXABI *ASTContext::createCXXABI(const TargetInfo &T) {
   case TargetCXXABI::GenericARM: // Same as Itanium at this level
   case TargetCXXABI::iOS:
   case TargetCXXABI::iOS64:
   case TargetCXXABI::WatchOS:
   case TargetCXXABI::GenericAArch64:
   case TargetCXXABI::GenericMIPS:
   case TargetCXXABI::GenericItanium:
   case TargetCXXABI::WebAssembly:
+  case TargetCXXABI::XL:
     return CreateItaniumCXXABI(*this);
   case TargetCXXABI::Microsoft:
     return CreateMicrosoftCXXABI(*this);
   }
   llvm_unreachable("Invalid CXXABI type!");
 }
 
 interp::Context &ASTContext::getInterpContext() {
MangleContext *ASTContext::createMangleContext(const TargetInfo *T) {
   case TargetCXXABI::GenericAArch64:
   case TargetCXXABI::GenericItanium:
   case TargetCXXABI::GenericARM:
   case TargetCXXABI::GenericMIPS:
   case TargetCXXABI::iOS:
   case TargetCXXABI::iOS64:
   case TargetCXXABI::WebAssembly:
   case TargetCXXABI::WatchOS:
+  case TargetCXXABI::XL:
     return ItaniumMangleContext::create(*this, getDiagnostics());
   case TargetCXXABI::Microsoft:
     return MicrosoftMangleContext::create(*this, getDiagnostics());
   }
   llvm_unreachable("Unsupported ABI");
 }
 
 CXXABI::~CXXABI() = default;

clang/lib/Basic/Targets/OSTargets.h

void getOSDefines(const LangOptions &Opts, const llvm::Triple &Triple,
     if (Opts.CPlusPlus && Opts.WChar) {
       Builder.defineMacro("_WCHAR_T");
     }
   }
 
 public:
   AIXTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
       : OSTargetInfo<Target>(Triple, Opts) {
+    this->TheCXXABI.set(TargetCXXABI::XL);
+
     if (this->PointerWidth == 64) {
       this->WCharType = this->UnsignedInt;
     } else {
       this->WCharType = this->UnsignedShort;
     }
     this->UseZeroLengthBitfieldAlignment = true;
   }
 

clang/lib/CodeGen/CodeGenModule.cpp

static CGCXXABI *createCXXABI(CodeGenModule &CGM) {
   case TargetCXXABI::GenericAArch64:
   case TargetCXXABI::GenericARM:
   case TargetCXXABI::iOS:
   case TargetCXXABI::iOS64:
   case TargetCXXABI::WatchOS:
   case TargetCXXABI::GenericMIPS:
   case TargetCXXABI::GenericItanium:
   case TargetCXXABI::WebAssembly:
+  case TargetCXXABI::XL:
     return CreateItaniumCXXABI(CGM);
   case TargetCXXABI::Microsoft:
     return CreateMicrosoftCXXABI(CGM);
   }
 
   llvm_unreachable("invalid C++ ABI kind");
 }
 

clang/lib/CodeGen/ItaniumCXXABI.cpp

 private:
   bool HasThisReturn(GlobalDecl GD) const override {
     return isa<CXXConstructorDecl>(GD.getDecl()) ||
            (isa<CXXDestructorDecl>(GD.getDecl()) &&
             GD.getDtorType() != Dtor_Deleting);
   }
   bool canCallMismatchedFunctionType() const override { return false; }
 };
+
+class XLCXXABI final : public ItaniumCXXABI {
+public:
+  explicit XLCXXABI(CodeGen::CodeGenModule &CGM)
+      : ItaniumCXXABI(CGM) {}
+
+  void registerGlobalDtor(CodeGenFunction &CGF, const VarDecl &D,
+                          llvm::FunctionCallee dtor,
+                          llvm::Constant *addr) override;
+};
 }
 
 CodeGen::CGCXXABI *CodeGen::CreateItaniumCXXABI(CodeGenModule &CGM) {
   switch (CGM.getTarget().getCXXABI().getKind()) {
   // For IR-generation purposes, there's no significant difference
   // between the ARM and iOS ABIs.
   case TargetCXXABI::GenericARM:
   case TargetCXXABI::iOS:
return new ItaniumCXXABI(CGM, /*UseARMMethodPtrABI=*/true,
                              /*UseARMGuardVarABI=*/true);
 
   case TargetCXXABI::GenericMIPS:
     return new ItaniumCXXABI(CGM, /*UseARMMethodPtrABI=*/true);
 
   case TargetCXXABI::WebAssembly:
     return new WebAssemblyCXXABI(CGM);
 
+  case TargetCXXABI::XL:
+    return new XLCXXABI(CGM);
+
   case TargetCXXABI::GenericItanium:
     if (CGM.getContext().getTargetInfo().getTriple().getArch()
         == llvm::Triple::le32) {
       // For PNaCl, use ARM-style method pointers so that PNaCl code
       // does not assume anything about the alignment of function
       // pointers.
       return new ItaniumCXXABI(CGM, /*UseARMMethodPtrABI=*/true);
     }

 
 void WebAssemblyCXXABI::emitBeginCatch(CodeGenFunction &CGF,
                                        const CXXCatchStmt *C) {
   if (CGF.getTarget().hasFeature("exception-handling"))
     CGF.EHStack.pushCleanup<CatchRetScope>(
         NormalCleanup, cast<llvm::CatchPadInst>(CGF.CurrentFuncletPad));
   ItaniumCXXABI::emitBeginCatch(CGF, C);
 }
+
+/// Register a global destructor as best as we know how.
+void XLCXXABI::registerGlobalDtor(CodeGenFunction &CGF, const VarDecl &D,
+                                  llvm::FunctionCallee dtor,
+                                  llvm::Constant *addr) {
+  llvm::report_fatal_error("Static initialization has not been implemented on"
+                           " XL ABI yet.");
+}

clang/test/CodeGen/static-init.cpp

+// RUN: not %clang_cc1 -triple powerpc-ibm-aix-xcoff -S -emit-llvm -x c++ %s \
+// RUN: 2>&1 | FileCheck %s
+
+// RUN: not %clang_cc1 -triple powerpc64-ibm-aix-xcoff -S -emit-llvm -x c++ %s \
+// RUN: 2>&1 | FileCheck %s
+
+struct test {
+  test();
+  ~test();
+} t;
+
+// CHECK: error in backend: Static initialization has not been implemented on XL ABI yet.