[MSP430] Expose msp430_builtin calling convention to C code

[atrosinenko]

Summary

According to MSP430 EABI document, Section 6.3, some of compiler helper functions require a special calling convention that is used for some of LibCalls accepting two 64-bit arguments.

As part of porting the compiler-rt builtins library to MSP430 I need to not only internally emit calls to these LibCalls but also to explicitly declare such functions in C code (for explicilty calling them from the unit test code) and to implement them in C (when I do not want to replace the generic C implementation with custom assembler code).

References: How to add an attribute chapter covers basics of adding a new attribute (not specifically calling convention-related).

[aaron.ballman]

clang/include/clang/Basic/Attr.td

1465

No new, undocumented attributes, please. Or is this attribute not expected to be used by users? (If it's not to be used by end users, is there a way we can skip exposing the attribute in the frontend and automatically generate the LLVM calling convention when lowering the builtin?)

clang/lib/Basic/Targets/MSP430.h

100

I think the lint warning about the formatting is actually correct in this case (but not in the other cases, unfortunately).

clang/lib/CodeGen/CGDebugInfo.cpp

1233

This is likely to cause -Werror failures because the switch won't be fully covered. Are you planning to do this TODO as part of this patch, or in a follow up?

clang/test/Sema/attr-msp430.c

15

Can you also add a sema test that the attribute accepts no arguments?

[rjmccall]

Is there only one special calling convention, or is there any chance that different builtin functions would use different conventions?

I don't have a problem with introducing a new convention even if it's only used for "builtin" functions.

[aaron.ballman]

In D84602#2176584, @rjmccall wrote:

I don't have a problem with introducing a new convention even if it's only used for "builtin" functions.

To be clear, I also don't have a problem with it, but if users aren't supposed to be writing this attribute themselves and if we can apply the calling convention from markings in a .def file instead, I think it could be a cleaner approach to go that route instead. There's a lot of "ifs" in that sentence though. :-)

[atrosinenko]

clang/include/clang/Basic/Attr.td

1465

Initially, it was not exposed and was just emitted according to the MSP430 EABI document, Section 6.3, as calls to libgcc. Now, when porting the builtins library of compiler-rt, I had to be able to

• define some of functions as a library function with a special calling convention
• declare external functions to be explicitly called from corresponding unit tests

So, it is not expected to mimic some existing attribute or be used by end users. Frankly speaking, it is possible it can change the meaning when finally wiring together all parts of MSP430 compiler-rt port. Ultimately, this is expected to be wired into D84636: [RFC] Make the default LibCall implementations from compiler-rt builtins library more customizable.

At the first glance, msp430-gcc just knows these functions by names and sets CC accordingly. This could technically solve my problem as well but looks quite hackish to me.

clang/lib/CodeGen/CGDebugInfo.cpp

1233

Are you planning to do this TODO as part of this patch, or in a follow up?

It depends on how large that change would be.

I first need to find out how such calling convention identifiers are issued (or maybe there already exist one from GCC). I see they are declared inside the llvm/include/llvm/BinaryFormat/Dwarf.def.

[aaron.ballman]

clang/include/clang/Basic/Attr.td

1465

At the first glance, msp430-gcc just knows these functions by names and sets CC accordingly. This could technically solve my problem as well but looks quite hackish to me.

I was thinking that MSP430 would have a BuiltinsMSP430.def file in include/clang/Basic, and you could specify the attribute on just the builtins that matter from within that file. But I notice there is no such file, so perhaps that idea won't work as well for you. If you add such a file, I think you'd attach your calling convention attributes somewhere near Sema::AddKnownFunctionAttributes() but you may have to do some work for the function type itself.

If we keep the explicit attribute, I'm fine with it being undocumented if users aren't supposed to write it themselves, but would appreciate some comments on the attribute explaining that.

clang/lib/CodeGen/CGDebugInfo.cpp

1233

I'm not certain how large the change would be (and I definitely don't insist on a full implementation), but you should ensure the switch is fully covered so that you don't break bots when the patch lands.

[atrosinenko]

In D84602#2176584, @rjmccall wrote:

Is there only one special calling convention, or is there any chance that different builtin functions would use different conventions?

It depends on how to define "builtin calling convention". Now it is in fact a "CC for builtin functions with two 64-bit arguments listed in Section 6.3 of EABI document". MSP430 EABI defines one such CC applied to a small subset of compiler helper functions, while others use the traditional CC like all other functions.

In D84602#2176592, @aaron.ballman wrote:

To be clear, I also don't have a problem with it, but if users aren't supposed to be writing this attribute themselves and if we can apply the calling convention from markings in a .def file instead, I think it could be a cleaner approach to go that route instead. There's a lot of "ifs" in that sentence though. :-)

Do you mean detecting these functions by their names, like GCC does? If so, that trick would replace all the

• D84602: [MSP430] Expose msp430_builtin calling convention to C code
• D84605: [IR][MSP430] Expose the "msp430_builtin" calling convention to .ll
• D84636: [RFC] Make the default LibCall implementations from compiler-rt builtins library more customizable

... provided this is considered as a generally suggested solution across the codebase, not a hack :)

[aaron.ballman]

In D84602#2178328, @atrosinenko wrote:

In D84602#2176592, @aaron.ballman wrote:

To be clear, I also don't have a problem with it, but if users aren't supposed to be writing this attribute themselves and if we can apply the calling convention from markings in a .def file instead, I think it could be a cleaner approach to go that route instead. There's a lot of "ifs" in that sentence though. :-)

Do you mean detecting these functions by their names, like GCC does? If so, that trick would replace all the

• D84602: [MSP430] Expose msp430_builtin calling convention to C code
• D84605: [IR][MSP430] Expose the "msp430_builtin" calling convention to .ll
• D84636: [RFC] Make the default LibCall implementations from compiler-rt builtins library more customizable

... provided this is considered as a generally suggested solution across the codebase, not a hack :)

I was envisioning specifying the builtins in a .def file like we do with other builtins, but allowing that .def file to specify optional calling convention information on a per-function basis (like we already support other attributes). So there would still be an LLVM attribute to be used, but there would not be a user-facing Clang attribute that users could misapply to their own code. So the attribute definition here would continue to exist, but the attribute would have no spelling associated with it. We do this with some other attributes, like AlignMac68kAttr or MaxFieldAlignmentAttr.

[atrosinenko]

Fix some review comments.

[atrosinenko]

I suspect there might be some terminology clash, so clarifying a bit just in case.

It was probably better to refer to these functions as LibCalls - functions from the compiler support library (such as libgcc) such as __adddf3. While there are __popcount[sdt]i2 among them, most of the times they are implicitly called when the high-level code performs division on __uint128, for example. Unfortunately, they reside under compiler-rt/lib/builtins - so that name was used... :) So, if I get it right, you have proposed something like clang/include/clang/Basic/BuiltinsMips.def and those are another kind of builtins.

The CallingConv::MSP430_BUILTIN was the name of a calling convention that the MSP430 codegen of LLVM had to use for a small subset of those support functions, as defined by MSP430 EABI. While it can be useful to add some other CC for those functions for internal use by compiler-rt someday, now there are only two CCs defined for MSP430 LibCalls: that "special convention" for 13 functions only with two 64-bit arguments (including 64-bit integer shifts) and the CallingConv::C for everything else both from the support library and regular object files.

Technically, these functions could probably be listed by names somewhere in the backend code, completely detangling the upstreaming of MSP430 compiler-rt port from D84602 (this one), D84605 and, the most scary of them, D84636. That may probably look a bit hackish, though.

[aaron.ballman]

Adding @echristo for the debugging info question.

In D84602#2200274, @atrosinenko wrote:

I suspect there might be some terminology clash, so clarifying a bit just in case.

Thank you for the explanations, they help!

It was probably better to refer to these functions as LibCalls - functions from the compiler support library (such as libgcc) such as __adddf3. While there are __popcount[sdt]i2 among them, most of the times they are implicitly called when the high-level code performs division on __uint128, for example. Unfortunately, they reside under compiler-rt/lib/builtins - so that name was used... :) So, if I get it right, you have proposed something like clang/include/clang/Basic/BuiltinsMips.def and those are another kind of builtins.

Ah! That explains my confusion -- I was indeed thinking of something like BuiltinMips.def and hadn't realized this was a different kind of builtin.

The CallingConv::MSP430_BUILTIN was the name of a calling convention that the MSP430 codegen of LLVM had to use for a small subset of those support functions, as defined by MSP430 EABI. While it can be useful to add some other CC for those functions for internal use by compiler-rt someday, now there are only two CCs defined for MSP430 LibCalls: that "special convention" for 13 functions only with two 64-bit arguments (including 64-bit integer shifts) and the CallingConv::C for everything else both from the support library and regular object files.

Technically, these functions could probably be listed by names somewhere in the backend code, completely detangling the upstreaming of MSP430 compiler-rt port from D84602 (this one), D84605 and, the most scary of them, D84636. That may probably look a bit hackish, though.

Given that these builtins are defined in source files rather than in a .td file, I agree that would be rather hackish and using syntax would be more appropriate.

clang/lib/CodeGen/CGDebugInfo.cpp

1233

I still think this case needs some work to keep the bots happy. I would probably go with:

case CC_MSP430Builtin:
  // FIXME: Currently unsupported
  break;

But perhaps @echristo has opinions since this involves debugging information.

[atrosinenko]

In D84602#2206512, @aaron.ballman wrote:

I still think this case needs some work to keep the bots happy. I would probably go with:

case CC_MSP430Builtin:

// FIXME: Currently unsupported
break;

But perhaps @echristo has opinions since this involves debugging information.

Agree, unless there exist some straightforward way to add a new vendor-specific extension to include/llvm/BinaryFormat/Dwarf.def. But I suspect there would be some standardization stuff and not sure it will actually be that useful.

[atrosinenko]

• Rebase onto current master branch
• Add a dummy switch case with FIXME, as suggested by @aaron.ballman
• Applied a couple of style fixes proposed by linter

[atrosinenko]

Pinging @echristo in case there is some trivial way to allocate a calling convention ID (but probably there is not, unless GCC allocated one already). As I understand, without this ID the debugger may show some misleading output for a limited number of LibCalls. On the other hand, it will not help either, unless the debugger knows this ID.

clang/include/clang/Basic/Attr.td

def MSP430Interrupt : InheritableAttr, TargetSpecificAttr<TargetMSP430> {
   // and AnyX86Interrupt's spellings must match.
   let Spellings = [GCC<"interrupt">];
   let Args = [UnsignedArgument<"Number">];
   let ParseKind = "Interrupt";
   let HasCustomParsing = 1;
   let Documentation = [Undocumented];
 }
 
+// For internal use by compiler-rt
+def MSP430Builtin : DeclOrTypeAttr, TargetSpecificAttr<TargetMSP430> {
+  let Spellings = [Clang<"msp430_builtin">];
+  let Documentation = [Undocumented];
+}
+
 def Mips16 : InheritableAttr, TargetSpecificAttr<TargetMips32> {
   let Spellings = [GCC<"mips16">];
   let Subjects = SubjectList<[Function], ErrorDiag>;
   let Documentation = [Undocumented];
 }
 
 def MipsInterrupt : InheritableAttr, TargetSpecificAttr<TargetMips32> {
   // NOTE: If you add any additional spellings, ARMInterrupt's,

clang/include/clang/Basic/Specifiers.h

#include "clang/Basic/OpenCLImageTypes.def"
   enum InClassInitStyle {
     ICIS_NoInit,   ///< No in-class initializer.
     ICIS_CopyInit, ///< Copy initialization.
     ICIS_ListInit  ///< Direct list-initialization.
   };
 
   /// CallingConv - Specifies the calling convention that a function uses.
   enum CallingConv {
     CC_C,           // __attribute__((cdecl))
     CC_X86StdCall,  // __attribute__((stdcall))
     CC_X86FastCall, // __attribute__((fastcall))
     CC_X86ThisCall, // __attribute__((thiscall))
     CC_X86VectorCall, // __attribute__((vectorcall))
     CC_X86Pascal,   // __attribute__((pascal))
     CC_Win64,       // __attribute__((ms_abi))
     CC_X86_64SysV,  // __attribute__((sysv_abi))
     CC_X86RegCall, // __attribute__((regcall))
     CC_AAPCS,       // __attribute__((pcs("aapcs")))
     CC_AAPCS_VFP,   // __attribute__((pcs("aapcs-vfp")))
     CC_IntelOclBicc, // __attribute__((intel_ocl_bicc))
     CC_SpirFunction, // default for OpenCL functions on SPIR target
     CC_OpenCLKernel, // inferred for OpenCL kernels
     CC_Swift,        // __attribute__((swiftcall))
     CC_PreserveMost, // __attribute__((preserve_most))
     CC_PreserveAll,  // __attribute__((preserve_all))
     CC_AArch64VectorCall, // __attribute__((aarch64_vector_pcs))
+    CC_MSP430Builtin, // __attribute__((msp430_builtin))
   };
 
   /// Checks whether the given calling convention supports variadic
   /// calls. Unprototyped calls also use the variadic call rules.
   inline bool supportsVariadicCall(CallingConv CC) {
     switch (CC) {
     case CC_X86StdCall:
     case CC_X86FastCall:

clang/lib/AST/ItaniumMangle.cpp

StringRef CXXNameMangler::getCallingConvQualifierName(CallingConv CC) {
   case CC_AAPCS:
   case CC_AAPCS_VFP:
   case CC_AArch64VectorCall:
   case CC_IntelOclBicc:
   case CC_SpirFunction:
   case CC_OpenCLKernel:
   case CC_PreserveMost:
   case CC_PreserveAll:
+  case CC_MSP430Builtin:
     // FIXME: we should be mangling all of the above.
     return "";
 
   case CC_X86ThisCall:
     // FIXME: To match mingw GCC, thiscall should only be mangled in when it is
     // used explicitly. At this point, we don't have that much information in
     // the AST, since clang tends to bake the convention into the canonical
     // function type. thiscall only rarely used explicitly, so don't mangle it

clang/lib/AST/Type.cpp

StringRef FunctionType::getNameForCallConv(CallingConv CC) {
   case CC_AAPCS_VFP: return "aapcs-vfp";
   case CC_AArch64VectorCall: return "aarch64_vector_pcs";
   case CC_IntelOclBicc: return "intel_ocl_bicc";
   case CC_SpirFunction: return "spir_function";
   case CC_OpenCLKernel: return "opencl_kernel";
   case CC_Swift: return "swiftcall";
   case CC_PreserveMost: return "preserve_most";
   case CC_PreserveAll: return "preserve_all";
+  case CC_MSP430Builtin: return "msp430_builtin";
   }
 
   llvm_unreachable("Invalid calling convention.");
 }
 
 FunctionProtoType::FunctionProtoType(QualType result, ArrayRef<QualType> params,
                                      QualType canonical,
                                      const ExtProtoInfo &epi)
bool AttributedType::isCallingConv() const {
   case attr::VectorCall:
   case attr::AArch64VectorPcs:
   case attr::Pascal:
   case attr::MSABI:
   case attr::SysVABI:
   case attr::IntelOclBicc:
   case attr::PreserveMost:
   case attr::PreserveAll:
+  case attr::MSP430Builtin:
     return true;
   }
   llvm_unreachable("invalid attr kind");
 }
 
 CXXRecordDecl *InjectedClassNameType::getDecl() const {
   return cast<CXXRecordDecl>(getInterestingTagDecl(Decl));
 }

clang/lib/AST/TypePrinter.cpp

case CC_Swift:
       OS << " __attribute__((swiftcall))";
       break;
     case CC_PreserveMost:
       OS << " __attribute__((preserve_most))";
       break;
     case CC_PreserveAll:
       OS << " __attribute__((preserve_all))";
       break;
+    case CC_MSP430Builtin:
+      OS << " __attribute__((msp430_builtin))";
+      break;
     }
   }
 
   if (Info.getNoReturn())
     OS << " __attribute__((noreturn))";
   if (Info.getCmseNSCall())
     OS << " __attribute__((cmse_nonsecure_call))";
   if (Info.getProducesResult())
case attr::AcquireHandle:
     OS << "acquire_handle";
     break;
   case attr::ArmMveStrictPolymorphism:
     OS << "__clang_arm_mve_strict_polymorphism";
     break;
   case attr::ArmSveVectorBits:
     OS << "arm_sve_vector_bits";
     break;
+  case attr::MSP430Builtin:
+    OS << "msp430_builtin";
+    break;
   }
   OS << "))";
 }
 
 void TypePrinter::printObjCInterfaceBefore(const ObjCInterfaceType *T,
                                            raw_ostream &OS) {
   OS << T->getDecl()->getName();
   spaceBeforePlaceHolder(OS);

clang/lib/Basic/Targets/MSP430.h

const char *getClobbers() const override {
     // FIXME: Is this really right?
     return "";
   }
 
   BuiltinVaListKind getBuiltinVaListKind() const override {
     // FIXME: implement
     return TargetInfo::CharPtrBuiltinVaList;
   }
+
+  CallingConvCheckResult checkCallingConvention(CallingConv CC) const override {
+    switch (CC) {
+    default:
+      return CCCR_Warning;
+    case CC_C:
+    case CC_MSP430Builtin:
+      return CCCR_OK;
+    }
+  }
 };
 
 } // namespace targets
 } // namespace clang
 #endif // LLVM_CLANG_LIB_BASIC_TARGETS_MSP430_H

clang/lib/CodeGen/CGCall.cpp

unsigned CodeGenTypes::ClangCallConvToLLVMCallConv(CallingConv CC) {
   // TODO: Add support for __vectorcall to LLVM.
   case CC_X86VectorCall: return llvm::CallingConv::X86_VectorCall;
   case CC_AArch64VectorCall: return llvm::CallingConv::AArch64_VectorCall;
   case CC_SpirFunction: return llvm::CallingConv::SPIR_FUNC;
   case CC_OpenCLKernel: return CGM.getTargetCodeGenInfo().getOpenCLKernelCallingConv();
   case CC_PreserveMost: return llvm::CallingConv::PreserveMost;
   case CC_PreserveAll: return llvm::CallingConv::PreserveAll;
   case CC_Swift: return llvm::CallingConv::Swift;
+  case CC_MSP430Builtin: return llvm::CallingConv::MSP430_BUILTIN;
   }
 }
 
 /// Derives the 'this' type for codegen purposes, i.e. ignoring method CVR
 /// qualification. Either or both of RD and MD may be null. A null RD indicates
 /// that there is no meaningful 'this' type, and a null MD can occur when
 /// calling a method pointer.
 CanQualType CodeGenTypes::DeriveThisType(const CXXRecordDecl *RD,
if (D->hasAttr<SysVABIAttr>())
     return IsWindows ? CC_X86_64SysV : CC_C;
 
   if (D->hasAttr<PreserveMostAttr>())
     return CC_PreserveMost;
 
   if (D->hasAttr<PreserveAllAttr>())
     return CC_PreserveAll;
 
+  if (D->hasAttr<MSP430BuiltinAttr>())
+    return CC_MSP430Builtin;
+
   return CC_C;
 }
 
 /// Arrange the argument and result information for a call to an
 /// unknown C++ non-static member function of the given abstract type.
 /// (A null RD means we don't have any meaningful "this" argument type,
 ///  so fall back to a generic pointer type).
 /// The member function must be an ordinary function, i.e. not a

clang/lib/CodeGen/CGDebugInfo.cpp

static unsigned getDwarfCC(CallingConv CC) {
   case CC_Swift:
     return llvm::dwarf::DW_CC_LLVM_Swift;
   case CC_PreserveMost:
     return llvm::dwarf::DW_CC_LLVM_PreserveMost;
   case CC_PreserveAll:
     return llvm::dwarf::DW_CC_LLVM_PreserveAll;
   case CC_X86RegCall:
     return llvm::dwarf::DW_CC_LLVM_X86RegCall;
+  // TODO case CC_MSP430Builtin:
   }
   return 0;
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const FunctionType *Ty,
                                       llvm::DIFile *Unit) {
   SmallVector<llvm::Metadata *, 16> EltTys;
 

clang/lib/Sema/SemaDeclAttr.cpp

case ParsedAttr::AT_IntelOclBicc:
     D->addAttr(::new (S.Context) IntelOclBiccAttr(S.Context, AL));
     return;
   case ParsedAttr::AT_PreserveMost:
     D->addAttr(::new (S.Context) PreserveMostAttr(S.Context, AL));
     return;
   case ParsedAttr::AT_PreserveAll:
     D->addAttr(::new (S.Context) PreserveAllAttr(S.Context, AL));
     return;
+  case ParsedAttr::AT_MSP430Builtin:
+    D->addAttr(::new (S.Context) MSP430BuiltinAttr(S.Context, AL));
+    return;
   default:
     llvm_unreachable("unexpected attribute kind");
   }
 }
 
 static void handleSuppressAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   if (!checkAttributeAtLeastNumArgs(S, AL, 1))
     return;
case ParsedAttr::AT_IntelOclBicc:
     CC = CC_IntelOclBicc;
     break;
   case ParsedAttr::AT_PreserveMost:
     CC = CC_PreserveMost;
     break;
   case ParsedAttr::AT_PreserveAll:
     CC = CC_PreserveAll;
     break;
+  case ParsedAttr::AT_MSP430Builtin:
+    CC = CC_MSP430Builtin;
+    break;
   default: llvm_unreachable("unexpected attribute kind");
   }
 
   TargetInfo::CallingConvCheckResult A = TargetInfo::CCCR_OK;
   const TargetInfo &TI = Context.getTargetInfo();
   // CUDA functions may have host and/or device attributes which indicate
   // their targeted execution environment, therefore the calling convention
   // of functions in CUDA should be checked against the target deduced based
static void ProcessDeclAttribute(Sema &S, Scope *scope, Decl *D,
   case ParsedAttr::AT_VectorCall:
   case ParsedAttr::AT_MSABI:
   case ParsedAttr::AT_SysVABI:
   case ParsedAttr::AT_Pcs:
   case ParsedAttr::AT_IntelOclBicc:
   case ParsedAttr::AT_PreserveMost:
   case ParsedAttr::AT_PreserveAll:
   case ParsedAttr::AT_AArch64VectorPcs:
+  case ParsedAttr::AT_MSP430Builtin:
     handleCallConvAttr(S, D, AL);
     break;
   case ParsedAttr::AT_Suppress:
     handleSuppressAttr(S, D, AL);
     break;
   case ParsedAttr::AT_Owner:
   case ParsedAttr::AT_Pointer:
     handleLifetimeCategoryAttr(S, D, AL);

clang/lib/Sema/SemaType.cpp

#define CALLING_CONV_ATTRS_CASELIST                                            \
   case ParsedAttr::AT_SwiftCall:                                               \
   case ParsedAttr::AT_VectorCall:                                              \
   case ParsedAttr::AT_AArch64VectorPcs:                                        \
   case ParsedAttr::AT_MSABI:                                                   \
   case ParsedAttr::AT_SysVABI:                                                 \
   case ParsedAttr::AT_Pcs:                                                     \
   case ParsedAttr::AT_IntelOclBicc:                                            \
   case ParsedAttr::AT_PreserveMost:                                            \
-  case ParsedAttr::AT_PreserveAll
+  case ParsedAttr::AT_PreserveAll:                                             \
+  case ParsedAttr::AT_MSP430Builtin
 
 // Function type attributes.
 #define FUNCTION_TYPE_ATTRS_CASELIST                                           \
   case ParsedAttr::AT_NSReturnsRetained:                                       \
   case ParsedAttr::AT_NoReturn:                                                \
   case ParsedAttr::AT_Regparm:                                                 \
   case ParsedAttr::AT_CmseNSCall:                                              \
   case ParsedAttr::AT_AnyX86NoCallerSavedRegisters:                            \
static Attr *getCCTypeAttr(ASTContext &Ctx, ParsedAttr &Attr) {
   case ParsedAttr::AT_MSABI:
     return createSimpleAttr<MSABIAttr>(Ctx, Attr);
   case ParsedAttr::AT_SysVABI:
     return createSimpleAttr<SysVABIAttr>(Ctx, Attr);
   case ParsedAttr::AT_PreserveMost:
     return createSimpleAttr<PreserveMostAttr>(Ctx, Attr);
   case ParsedAttr::AT_PreserveAll:
     return createSimpleAttr<PreserveAllAttr>(Ctx, Attr);
+  case ParsedAttr::AT_MSP430Builtin:
+    return createSimpleAttr<MSP430BuiltinAttr>(Ctx, Attr);
   }
   llvm_unreachable("unexpected attribute kind!");
 }
 
 /// Process an individual function attribute.  Returns true to
 /// indicate that the attribute was handled, false if it wasn't.
 static bool handleFunctionTypeAttr(TypeProcessingState &state, ParsedAttr &attr,
                                    QualType &type) {

clang/test/CodeGen/msp430-cc-builtin.c

+// RUN: %clang_cc1 -triple msp430 -emit-llvm < %s | FileCheck %s
+
+__attribute__((msp430_builtin)) int f(long long x, long long y);
+
+__attribute__((msp430_builtin)) int g(long long x, long long y) {
+  return (int)42;
+}
+// CHECK: define cc94 {{(dso_local )?}}i16 @g(i64 %x, i64 %y)
+
+int caller()
+{
+  return f(0, 0);
+// CHECK: call cc94 i16 @f
+}
+
+// CHECK: declare cc94 {{(dso_local )?}}i16 @f(i64, i64)

clang/test/Sema/attr-msp430.c

 // RUN: %clang_cc1 -triple msp430-unknown-unknown -fsyntax-only -verify %s
 
 __attribute__((interrupt(1))) int t; // expected-warning {{'interrupt' attribute only applies to functions}}
 
 int i;
 __attribute__((interrupt(i))) void f(void); // expected-error {{'interrupt' attribute requires an integer constant}}
 __attribute__((interrupt(1, 2))) void f2(void); // expected-error {{'interrupt' attribute takes one argument}}
 __attribute__((interrupt(1))) int f3(void); // expected-warning {{MSP430 'interrupt' attribute only applies to functions that have a 'void' return type}}
 __attribute__((interrupt(1))) void f4(int a); // expected-warning {{MSP430 'interrupt' attribute only applies to functions that have no parameters}}
 __attribute__((interrupt(64))) void f5(void); // expected-error {{'interrupt' attribute parameter 64 is out of bounds}}
 
 __attribute__((interrupt(0))) void f6(void);
 __attribute__((interrupt(63))) void f7(void);
+
+__attribute__((msp430_builtin)) int t2; // expected-warning {{'msp430_builtin' only applies to function types; type here is 'int'}}
+__attribute__((msp430_builtin(1))) void f8(long long a, long long b); // expected-error {{'msp430_builtin' attribute takes no arguments}}
+__attribute__((msp430_builtin)) void f9(long long a, long long b);

clang/tools/libclang/CXType.cpp

switch (FD->getCallConv()) {
       TCALLINGCONV(Win64);
       TCALLINGCONV(X86_64SysV);
       TCALLINGCONV(AAPCS);
       TCALLINGCONV(AAPCS_VFP);
       TCALLINGCONV(IntelOclBicc);
       TCALLINGCONV(Swift);
       TCALLINGCONV(PreserveMost);
       TCALLINGCONV(PreserveAll);
+    case CC_MSP430Builtin: return CXCallingConv_Unexposed;
     case CC_SpirFunction: return CXCallingConv_Unexposed;
     case CC_OpenCLKernel: return CXCallingConv_Unexposed;
       break;
     }
 #undef TCALLINGCONV
   }
   
   return CXCallingConv_Invalid;

llvm/lib/Target/MSP430/MSP430ISelLowering.cpp

SDValue MSP430TargetLowering::LowerFormalArguments(
     const SmallVectorImpl<ISD::InputArg> &Ins, const SDLoc &dl,
     SelectionDAG &DAG, SmallVectorImpl<SDValue> &InVals) const {
 
   switch (CallConv) {
   default:
     report_fatal_error("Unsupported calling convention");
   case CallingConv::C:
   case CallingConv::Fast:
+  case CallingConv::MSP430_BUILTIN:
     return LowerCCCArguments(Chain, CallConv, isVarArg, Ins, dl, DAG, InVals);
   case CallingConv::MSP430_INTR:
     if (Ins.empty())
       return Chain;
     report_fatal_error("ISRs cannot have arguments");
   }
 }