[PPC] PPC32/Darwin ABI info

[kparzysz]

Summary

Use the default implementation of EmitVAArg instead of the SVR4 one. This is meant to address PR33108.

The motivating testcase:

void foo() {
  __builtin_va_list va;
  __builtin_va_arg(va, int);
}

Compiling with clang -target powerpc-unknown-macosx -S test.c results in a crash.

[kparzysz]

Add implementation of EmitVAArg and explicitly call emitVoidPtrVAArg in it.

[kparzysz]

This patch corrects the ABI alignment issues for arguments of size greater than 4: all types except vector and aggregates will be aligned at 4-byte boundary in the parameter area. Vectors and aggregates will follow their natural alignment.

[kparzysz]

Ping. The bug reporter has verified that this patch fixes the problem.

[nemanjai]

I'm not sure how much expertise there is for PPC32-Darwin. Perhaps @iains might be able to offer some insight here. Also, @echristo might have a thing or two to say in this regard.

[iains]

This seems like a reasonable start, and is a step forward.
For the VAArgs, this will be self-consistent, but to be compliant with the system ABI, I think you'll need to account the different padding rules for small aggregates, as per pp14 of "Mac_OS_X_ABI_Function_Calls". Specifically, 1 and 2 byte aggregates are right-aligned and padded on the left, but sizes 3 and above are left-aligned and padded on the right.

I have a more complete ABIInfo implementation, but it needs forward-porting to trunk. Will let you know when that's done.

[kparzysz]

Great! Thanks.

[ken-cunningham-webuse]

@iains - I have interest in resolving this issue, and also a couple of other lingering bugs in the PPC32Darwin ABI realm. If you have your WIP available anywhere, I'd be happy to have a go at bringing it up to current.

[nemanjai]

In D33499#1341236, @ken-cunningham-webuse wrote:

@iains - I have interest in resolving this issue, and also a couple of other lingering bugs in the PPC32Darwin ABI realm. If you have your WIP available anywhere, I'd be happy to have a go at bringing it up to current.

A decision was made a while ago to remove Darwin support from the PPC back end. This was decided due to very little use of the code and essentially no maintenance being done on it. I think that support was already turned off in ToT with the plan to slowly rip out the code over the next couple of releases. So I believe that any improvements you plan to make it will need to be done on an older release out of tree unless you can make a compelling case for keeping this support in LLVM. Tagging some of the interested parties (@kbarton @hfinkel @echristo).

[iains]

Since that's my understanding too - I am (slowly) bringing my patches forward to 7.0 - at the moment testing the MC layer changes on powerpc-darwin9 (looking reasonable, as an assembler for GCC, so far). When things are "ready" (at least not broken as far as I can tell) - will push them to my github (iains).

I think the parting comment was that if /when it's coherent enough to warrant re-inclusion (or there are enough developer cycles to maintain it)... then that could be discussed.

[ken-cunningham-webuse]

I saw that idea floated but didn't see that it was accepted. I don't know exactly how much interest there is in darwin PPC. There are new tickets about Darwin PPC within the past few months. I see plenty of questions about it on the MacPorts boards.

I have clang/llvm-5.0 and clang/llvm-3.8 running now on 10.5 PPC with a 98% pass on the test suite. I use it to build things on a daily basis. The compiler_rt build is messy still, otherwise I would push it to MacPorts now.

AFAICT, darwin PPC is missing only support for non-default exceptions (there is a ticket about that), and this va_args thing. Everything else seems to be working and intact.

I have the patch in this ticket already incorporated in my builds.

[ken-cunningham-webuse]

I found the relevant recent discussions on the mailing list, and the commits from August that started the Darwin PPC withdrawal from the source.

I have this patch in my local folder of llvm/darwinppc fixes. I suppose this ticket might be closed then?

lib/CodeGen/TargetInfo.cpp

PPC32TargetCodeGenInfo::initDwarfEHRegSizeTable(CodeGen::CodeGenFunction &CGF,
   // 111: spe_acc
   // 112: spefscr
   // 113: sfp
   AssignToArrayRange(Builder, Address, Four8, 109, 113);
 
   return false;
 }
 
+namespace {
+/// PPC32_Darwin_ABIInfo - The 32-bit PowerPC Darwin ABI information.
+class PPC32_Darwin_ABIInfo : public DefaultABIInfo {
+public:
+  PPC32_Darwin_ABIInfo(CodeGen::CodeGenTypes &CGT) : DefaultABIInfo(CGT) {}
+
+  Address EmitVAArg(CodeGenFunction &CGF, Address VAListAddr,
+                    QualType Ty) const override;
+};
+
+class PPC32DarwinTargetCodeGenInfo : public TargetCodeGenInfo {
+public:
+  PPC32DarwinTargetCodeGenInfo(CodeGenTypes &CGT)
+      : TargetCodeGenInfo(new PPC32_Darwin_ABIInfo(CGT)) {}
+
+  int getDwarfEHStackPointer(CodeGen::CodeGenModule &M) const override {
+    // This is recovered from gcc output.
+    return 1; // r1 is the dedicated stack pointer
+  }
+
+  bool initDwarfEHRegSizeTable(CodeGen::CodeGenFunction &CGF,
+                               llvm::Value *Address) const override;
+};
+}
+
+Address PPC32_Darwin_ABIInfo::EmitVAArg(CodeGenFunction &CGF,
+                                        Address VAListAddr,
+                                        QualType Ty) const {
+  // Cap the alignment of function arguments to the natural stack alignment
+  // for all types, except vectors and aggregates.
+  std::pair<CharUnits, CharUnits> Info = getContext().getTypeInfoInChars(Ty);
+  CharUnits Slot = CharUnits::fromQuantity(4);
+  if (!Ty->isVectorType() && !isAggregateTypeForABI(Ty))
+    Info.second = std::min(Info.second, Slot);
+
+  return emitVoidPtrVAArg(CGF, VAListAddr, Ty, /*Indirect=*/ false,
+                          Info, Slot, /*AllowHigherAlign=*/ true);
+}
+
+// Copied from PP32TargetCodeGenInfo.
+bool
+PPC32DarwinTargetCodeGenInfo::initDwarfEHRegSizeTable(
+      CodeGen::CodeGenFunction &CGF, llvm::Value *Address) const {
+  // This is calculated from the LLVM and GCC tables and verified
+  // against gcc output.  AFAIK all ABIs use the same encoding.
+
+  CodeGen::CGBuilderTy &Builder = CGF.Builder;
+
+  llvm::IntegerType *i8 = CGF.Int8Ty;
+  llvm::Value *Four8 = llvm::ConstantInt::get(i8, 4);
+  llvm::Value *Eight8 = llvm::ConstantInt::get(i8, 8);
+  llvm::Value *Sixteen8 = llvm::ConstantInt::get(i8, 16);
+
+  // 0-31: r0-31, the 4-byte general-purpose registers
+  AssignToArrayRange(Builder, Address, Four8, 0, 31);
+
+  // 32-63: fp0-31, the 8-byte floating-point registers
+  AssignToArrayRange(Builder, Address, Eight8, 32, 63);
+
+  // 64-76 are various 4-byte special-purpose registers:
+  // 64: mq
+  // 65: lr
+  // 66: ctr
+  // 67: ap
+  // 68-75 cr0-7
+  // 76: xer
+  AssignToArrayRange(Builder, Address, Four8, 64, 76);
+
+  // 77-108: v0-31, the 16-byte vector registers
+  AssignToArrayRange(Builder, Address, Sixteen8, 77, 108);
+
+  // 109: vrsave
+  // 110: vscr
+  // 111: spe_acc
+  // 112: spefscr
+  // 113: sfp
+  AssignToArrayRange(Builder, Address, Four8, 109, 113);
+
+  return false;
+}
+
 // PowerPC-64
 
 namespace {
 /// PPC64_SVR4_ABIInfo - The 64-bit PowerPC ELF (SVR4) ABI information.
 class PPC64_SVR4_ABIInfo : public ABIInfo {
 public:
   enum ABIKind {
     ELFv1 = 0,
else if (CodeGenOpts.FloatABI == "hard" ||
                Triple.getEnvironment() == llvm::Triple::MuslEABIHF ||
                Triple.getEnvironment() == llvm::Triple::EABIHF)))
       Kind = ARMABIInfo::AAPCS_VFP;
 
     return SetCGInfo(new ARMTargetCodeGenInfo(Types, Kind));
   }
 
   case llvm::Triple::ppc:
+    if (Triple.isOSDarwin())
+      return SetCGInfo(new PPC32DarwinTargetCodeGenInfo(Types));
     return SetCGInfo(
         new PPC32TargetCodeGenInfo(Types, CodeGenOpts.FloatABI == "soft"));
   case llvm::Triple::ppc64:
     if (Triple.isOSBinFormatELF()) {
       PPC64_SVR4_ABIInfo::ABIKind Kind = PPC64_SVR4_ABIInfo::ELFv1;
       if (getTarget().getABI() == "elfv2")
         Kind = PPC64_SVR4_ABIInfo::ELFv2;
       bool HasQPX = getTarget().getABI() == "elfv1-qpx";