[AArch64][SVE] Add aarch64_sve_pcs attribute to Clang

[MattDevereau]

Summary

[AArch64][SVE] Add aarch64_sve_pcs attribute to Clang

Enable function attribute aarch64_sve_pcs at the C level, which correspondes to aarch64_sve_vector_pcs at the LLVM IR level.

This requirement was created by this addition to the ARM C Language Extension:
https://github.com/ARM-software/acle/pull/194

[peterwaller-arm]

Looks good to me with minor nits.

clang/include/clang-c/Index.h

3448

It shouldn't matter in principle (... "but in practice" ...) we should probably avoid renumbering existing things in the enum and instead add to the end of it.

Nit, this is missing a space before the equals.
Nit, SVE is an acronym, so is PCS, so capitalization should be consistent between the two. I see 'PCS' capitalized in AAPCS for example so probably all upper case makes the sense.

[peterwaller-arm]

clang/include/clang-c/Index.h

3448

I retract my sloppy "it shouldn't matter in principle [at the source level]", of course it does matter, and it likely matters in this case (see 'alias for compatibility' comment above).

To be more specific, changing the enum is an ABI break, and breaks if these things are ever serialized and therefore not something you want to do.

[aaron.ballman]

clang/include/clang-c/Index.h

3448

+1 -- I was just making that comment when you beat me to it.

clang/include/clang/Basic/Specifiers.h

283

I continue to be concerned with how many custom calling conventions we're adding. We're running out of bits to store them and when we bump up against the next limitation (32 possible calling conventions, this patch brings us up to 20), we're going to lose a significant amount of performance due to extra memory overhead pressure (which, in turn, will greatly reduce our maximum template instantiation depth) with no clear path forward. We've looked into this before and once we hit that 32 calling convention limit, we won't be adding any new calling conventions until we solve the memory pressure problem.

Are there other alternatives than making a new calling convention? (e.g., can this be handled with a backend pass somehow, or some other implementation strategy?)
Is this calling convention going to be used often enough to warrant adding it? (e.g., will this be showing up in system headers or other major third-party library headers, or is this a one-off for people trying to eek the last ounce of performance out of a function call?)

[aaron.ballman]

Making it clear there are necessary changes (at least to unbreak the C ABI).

[tschuett]

clang/include/clang-c/Index.h

3448

Could you please add your CC as 18 and add a comment the next CC will 19 and do not touch the other ones.

[erichkeane]

clang/include/clang/Basic/Specifiers.h

283

I agree with this, our list of calling conventions needs to find a way to get smaller, not larger. our ExtInfo is already shocking/frighteningly large use of bits with calling conventions taking 5. IMO, we should reduce this to 4 bits if at all possible, particularly since we're likely to need more bits in the function-type thanks to the C++ committee.

Internally, Ive been fighting pretty hard to keep us from extending this list unless at all possible, and I think we need to do so here.

[paulwalker-arm]

Just wanted to say this is not a new calling convention as such, but rather an existing one that is generally auto-detected based on function signature. The problem we're trying to solve here is that we need a way to allow a user to force the calling convention when the function signature would not normally choose it.

[MattDevereau]

set CXCallingConv_AArch64SVEPcs= 17 to 18 to resolve ABI break
renamed CC_AArch64SVEPcs to CC_AArch64SVEPCS

[aaron.ballman]

In D124998#3493791, @paulwalker-arm wrote:

Just wanted to say this is not a new calling convention as such, but rather an existing one that is generally auto-detected based on function signature. The problem we're trying to solve here is that we need a way to allow a user to force the calling convention when the function signature would not normally choose it.

Thanks for this information! It's still not clear to me whether there's sufficient need for this extension. From this description, it sounds like this will be rarely used because it's only necessary in one-off situations. If that's correct, can those users make use of inline assembly instead of a devoted named calling convention?

[paulwalker-arm]

In D124998#3494127, @aaron.ballman wrote:

In D124998#3493791, @paulwalker-arm wrote:

Just wanted to say this is not a new calling convention as such, but rather an existing one that is generally auto-detected based on function signature. The problem we're trying to solve here is that we need a way to allow a user to force the calling convention when the function signature would not normally choose it.

Thanks for this information! It's still not clear to me whether there's sufficient need for this extension. From this description, it sounds like this will be rarely used because it's only necessary in one-off situations. If that's correct, can those users make use of inline assembly instead of a devoted named calling convention?

It's hard to say how often this will be used but when used it will be fundamental to performance. I don't see inline assembly as a workable solution. It presents an unreasonable burden on a framework's user and will impact compiler optimisations. The ACLE exists to stop developers from needing to use inline assembly.

You have to forgive my naivety here but some of the calling conventions are target specific. Is it possible for them to safely alias for the parts of the code where memory is constrained? Or to put it another way, do the X86 and AArch64 calling conventions need to be uniquely identifiable?

[erichkeane]

In D124998#3494388, @paulwalker-arm wrote:

In D124998#3494127, @aaron.ballman wrote:

In D124998#3493791, @paulwalker-arm wrote:

Just wanted to say this is not a new calling convention as such, but rather an existing one that is generally auto-detected based on function signature. The problem we're trying to solve here is that we need a way to allow a user to force the calling convention when the function signature would not normally choose it.

Thanks for this information! It's still not clear to me whether there's sufficient need for this extension. From this description, it sounds like this will be rarely used because it's only necessary in one-off situations. If that's correct, can those users make use of inline assembly instead of a devoted named calling convention?

It's hard to say how often this will be used but when used it will be fundamental to performance. I don't see inline assembly as a workable solution. It presents an unreasonable burden on a framework's user and will impact compiler optimisations. The ACLE exists to stop developers from needing to use inline assembly.

You have to forgive my naivety here but some of the calling conventions are target specific. Is it possible for them to safely alias for the parts of the code where memory is constrained? Or to put it another way, do the X86 and AArch64 calling conventions need to be uniquely identifiable?

This would alleviate my concerns if we were to do something like that. It _IS_ quite unfair how many calling convention bits we burn on old 32-bit-MSVC and X86/x86-64 calling conventions that don't seem particularly well used/valuable.

I looked into doing that at one point about 2 years ago, but it ended up being not possible/beneficial thanks to our multi-target-at-the-same-time compilation model for offload. Basically: we need to identify TWO calling convention lists at the same time, and there are combos that result in us having more than 16 items, thus not saving any bits. If you can come up with a way of doing this that I was unable to come up with at the time, I'm all for it! At that point, it would be up to the individual targets to manage themselves in a way to stay sub-16.

[efriedma]

If you're really concerned about the size of FunctionProtoType increasing, can we just shove the infrequently used calling convention bits into TrailingObjects?

[erichkeane]

In D124998#3494424, @efriedma wrote:

If you're really concerned about the size of FunctionProtoType increasing, can we just shove the infrequently used calling convention bits into TrailingObjects?

I don't believe so. These are parts of the bitfield and are intrinsic to the type.

[efriedma]

In D124998#3494426, @erichkeane wrote:

In D124998#3494424, @efriedma wrote:

If you're really concerned about the size of FunctionProtoType increasing, can we just shove the infrequently used calling convention bits into TrailingObjects?

I don't believe so. These are parts of the bitfield and are intrinsic to the type.

I don't follow. Everything stored in FunctionProtoType, including information stored in TrailingObjects, is "intrinsic to the type". It's just stored differently. (FunctionTypeExtraBitfields already exists, even...)

[tschuett]

clang/include/clang-c/Index.h

3448

Do you want to add a static_assert to prevent people from doing stupid things?

[erichkeane]

In D124998#3494442, @efriedma wrote:

In D124998#3494426, @erichkeane wrote:

In D124998#3494424, @efriedma wrote:

If you're really concerned about the size of FunctionProtoType increasing, can we just shove the infrequently used calling convention bits into TrailingObjects?

I don't believe so. These are parts of the bitfield and are intrinsic to the type.

I don't follow. Everything stored in FunctionProtoType, including information stored in TrailingObjects, is "intrinsic to the type". It's just stored differently. (FunctionTypeExtraBitfields already exists, even...)

Ah, I see what you mean. I misread and thought you meant on the FunctionDecl itself, so mea culpa.

I was unaware of FunctionTypeExtraBitfields! We perhaps should consider what of the ExtInfo we can move over to the FunctionTypeExtraBitfields. In that list, there are MAYBE 5 bits of the 13 that are used with any level of commonness (though I have no idea what CmseNSCall means). If most of those moved, I'd be pretty ok with having even EXTRA bits added for calling convention (though, if we go over 32, we probably need to have a discussion as to whether they are valuable).

[aaron.ballman]

In D124998#3494500, @erichkeane wrote:

In D124998#3494442, @efriedma wrote:

In D124998#3494426, @erichkeane wrote:

In D124998#3494424, @efriedma wrote:

If you're really concerned about the size of FunctionProtoType increasing, can we just shove the infrequently used calling convention bits into TrailingObjects?

I don't believe so. These are parts of the bitfield and are intrinsic to the type.

I don't follow. Everything stored in FunctionProtoType, including information stored in TrailingObjects, is "intrinsic to the type". It's just stored differently. (FunctionTypeExtraBitfields already exists, even...)

Ah, I see what you mean. I misread and thought you meant on the FunctionDecl itself, so mea culpa.

I was unaware of FunctionTypeExtraBitfields! We perhaps should consider what of the ExtInfo we can move over to the FunctionTypeExtraBitfields. In that list, there are MAYBE 5 bits of the 13 that are used with any level of commonness (though I have no idea what CmseNSCall means). If most of those moved, I'd be pretty ok with having even EXTRA bits added for calling convention (though, if we go over 32, we probably need to have a discussion as to whether they are valuable).

Not to be a party pooper, but that only works for FunctionProtoType and users can write calling conventions on functions without prototypes too, which has no trailing objects currently. However, functions without prototypes aren't a worry for deep template instantiations or the like (because they don't exist in C++), and if users are making heavy use of functions without prototypes (never been a feature in any ISO C standard), I don't particularly mind if their compilation goes slower because we now need to tail allocate data for each non-prototype function. However, we should be careful not to duplicate code as I'm pretty sure that's why ExtInfo is in FunctionType in the first place (there's no way to add a trailing object to FunctionType because it's subclassed).

[erichkeane]

In D124998#3494785, @aaron.ballman wrote:

In D124998#3494500, @erichkeane wrote:

In D124998#3494442, @efriedma wrote:

In D124998#3494426, @erichkeane wrote:

In D124998#3494424, @efriedma wrote:

If you're really concerned about the size of FunctionProtoType increasing, can we just shove the infrequently used calling convention bits into TrailingObjects?

I don't believe so. These are parts of the bitfield and are intrinsic to the type.

I don't follow. Everything stored in FunctionProtoType, including information stored in TrailingObjects, is "intrinsic to the type". It's just stored differently. (FunctionTypeExtraBitfields already exists, even...)

Ah, I see what you mean. I misread and thought you meant on the FunctionDecl itself, so mea culpa.

I was unaware of FunctionTypeExtraBitfields! We perhaps should consider what of the ExtInfo we can move over to the FunctionTypeExtraBitfields. In that list, there are MAYBE 5 bits of the 13 that are used with any level of commonness (though I have no idea what CmseNSCall means). If most of those moved, I'd be pretty ok with having even EXTRA bits added for calling convention (though, if we go over 32, we probably need to have a discussion as to whether they are valuable).

Not to be a party pooper, but that only works for FunctionProtoType and users can write calling conventions on functions without prototypes too, which has no trailing objects currently. However, functions without prototypes aren't a worry for deep template instantiations or the like (because they don't exist in C++), and if users are making heavy use of functions without prototypes (never been a feature in any ISO C standard), I don't particularly mind if their compilation goes slower because we now need to tail allocate data for each non-prototype function. However, we should be careful not to duplicate code as I'm pretty sure that's why ExtInfo is in FunctionType in the first place (there's no way to add a trailing object to FunctionType because it's subclassed).

First: I care very little about FunctionNoProtoType. Second, it is used only in "C" afaik, where our memory pressure isn't that big of a deal. I'd be OK with having the FunctionTypeExtraBits be just added to FunctionNoProtoType, but stay in FunctionProtoType trailing storage.

It WOULD be more work, but I would wonder if we could combine all 3 classes into FunctionType and replace the NoProtoType-ness with a single bit to differentiate. The result is the non-prototyped versions needing to carry around extra information, but since:
a- our C implementation has low memory pressure
b- prototypeless functions were a mistake

I would think the extra memory they end up carrying might be ok?

[efriedma]

I don't want to change with the distinction between FunctionProtoType and FunctionNoProtoType; that would involve auditing a bunch of code we don't really want to mess with.

FunctionProtoType and FunctionNoProtoType don't have any member variables at the moment, though. The only difference is that FunctionProtoType has TrailingObjects, and FunctionNoProtoType doesn't. It should be fine to just require the same TrailingObjects for FunctionNoProtoType. So FunctionProtoType and FunctionNoProtoType would have the same memory layout.

[aaron.ballman]

In D124998#3494814, @erichkeane wrote:

First: I care very little about FunctionNoProtoType.

I care insomuch as it doesn't break valid user code.

Second, it is used only in "C" afaik, where our memory pressure isn't that big of a deal. I'd be OK with having the FunctionTypeExtraBits be just added to FunctionNoProtoType, but stay in FunctionProtoType trailing storage.

I agree that the memory pressure here shouldn't be overly concerning, and I would most likely be okay if we adds the bits that way. However, I think we could also just make FunctionNoProtoType have the same memory layout as FunctionProtoType by using trailing objects again.

It WOULD be more work, but I would wonder if we could combine all 3 classes into FunctionType and replace the NoProtoType-ness with a single bit to differentiate. The result is the non-prototyped versions needing to carry around extra information, but since:
a- our C implementation has low memory pressure
b- prototypeless functions were a mistake

I would think the extra memory they end up carrying might be ok?

We do a fair amount of checks via isa<FunctionProtoType>() (or similar) that would need to be updated to check for a FunctionType and whether that bit is set, and I don't have a good handle on what that would do to the code. If it doesn't cause significant maintenance issues, I would still want to see some measurements for what it does to compiler performance on large projects (it'd be a good thing to try on http://llvm-compile-time-tracker.com/).

[paulwalker-arm]

@aaron.ballman It looks like the conversation reached a conclusion? Given this is separate to what we're trying to add here can this patch be unblocked?

[aaron.ballman]

In D124998#3503335, @paulwalker-arm wrote:

@aaron.ballman It looks like the conversation reached a conclusion? Given this is separate to what we're trying to add here can this patch be unblocked?

I continue to dislike adding more calling conventions, but the immediate concerns I had about running out of space are not too immediate and it sounds like we have a plausible way forward when we get closer to it. So I retract my blocking concerns -- this LGTM. Thanks for the discussion on this!

clang/include/clang-c/Index.h

enum CXCallingConv {
   CXCallingConv_X86_64Win64 = CXCallingConv_Win64,
   CXCallingConv_X86_64SysV = 11,
   CXCallingConv_X86VectorCall = 12,
   CXCallingConv_Swift = 13,
   CXCallingConv_PreserveMost = 14,
   CXCallingConv_PreserveAll = 15,
   CXCallingConv_AArch64VectorCall = 16,
   CXCallingConv_SwiftAsync = 17,
+  CXCallingConv_AArch64SVEPCS = 18,
 
   CXCallingConv_Invalid = 100,
   CXCallingConv_Unexposed = 200
 };
 
 /**
  * The type of an element in the abstract syntax tree.
  *

clang/include/clang/Basic/Attr.td

//  let Subjects = [Function, ObjCMethod];
   let Documentation = [PcsDocs];
 }
 
 def AArch64VectorPcs: DeclOrTypeAttr {
   let Spellings = [Clang<"aarch64_vector_pcs">];
   let Documentation = [AArch64VectorPcsDocs];
 }
 
+def AArch64SVEPcs: DeclOrTypeAttr {
+  let Spellings = [Clang<"aarch64_sve_pcs">];
+  let Documentation = [AArch64SVEPcsDocs];
+}
+
 def Pure : InheritableAttr {
   let Spellings = [GCC<"pure">];
   let Documentation = [Undocumented];
   let SimpleHandler = 1;
 }
 
 def Regparm : TypeAttr {
   let Spellings = [GCC<"regparm">];

clang/include/clang/Basic/AttrDocs.td

 
 For more information, see the documentation for `aarch64_vector_pcs`_ on
 the Arm Developer website.
 
 .. _`aarch64_vector_pcs`: https://developer.arm.com/products/software-development-tools/hpc/arm-compiler-for-hpc/vector-function-abi
   }];
 }
 
+def AArch64SVEPcsDocs : Documentation {
+  let Category = DocCatCallingConvs;
+  let Content = [{
+On AArch64 targets, this attribute changes the calling convention of a
+function to preserve additional Scalable Vector registers and Scalable
+Predicate registers relative to the default calling convention used for
+AArch64.
+
+This means it is more efficient to call such functions from code that performs
+extensive scalable vector and scalable predicate calculations, because fewer
+live SVE registers need to be saved. This property makes it well-suited for SVE
+math library functions, which are typically leaf functions that require a small
+number of registers.
+
+However, using this attribute also means that it is more expensive to call
+a function that adheres to the default calling convention from within such
+a function. Therefore, it is recommended that this attribute is only used
+for leaf functions.
+
+For more information, see the documentation for `aarch64_sve_pcs` in the
+ARM C Language Extension (ACLE) documentation.
+
+.. _`aarch64_sve_pcs`: https://github.com/ARM-software/acle/blob/main/main/acle.md#scalable-vector-extension-procedure-call-standard-attribute
+  }];
+}
+
 def RegparmDocs : Documentation {
   let Category = DocCatCallingConvs;
   let Content = [{
 On 32-bit x86 targets, the regparm attribute causes the compiler to pass
 the first three integer parameters in EAX, EDX, and ECX instead of on the
 stack. This attribute has no effect on variadic functions, and all parameters
 are passed via the stack as normal.
   }];

clang/include/clang/Basic/Specifiers.h

enum CallingConv {
     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_SwiftAsync,        // __attribute__((swiftasynccall))
     CC_PreserveMost, // __attribute__((preserve_most))
     CC_PreserveAll,  // __attribute__((preserve_all))
     CC_AArch64VectorCall, // __attribute__((aarch64_vector_pcs))
+    CC_AArch64SVEPCS, // __attribute__((aarch64_sve_pcs))
   };
 
   /// 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

case CC_C:
     return "";
 
   case CC_X86VectorCall:
   case CC_X86Pascal:
   case CC_X86RegCall:
   case CC_AAPCS:
   case CC_AAPCS_VFP:
   case CC_AArch64VectorCall:
+  case CC_AArch64SVEPCS:
   case CC_IntelOclBicc:
   case CC_SpirFunction:
   case CC_OpenCLKernel:
   case CC_PreserveMost:
   case CC_PreserveAll:
     // FIXME: we should be mangling all of the above.
     return "";
 

clang/lib/AST/Type.cpp

StringRef FunctionType::getNameForCallConv(CallingConv CC) {
   case CC_X86Pascal: return "pascal";
   case CC_X86VectorCall: return "vectorcall";
   case CC_Win64: return "ms_abi";
   case CC_X86_64SysV: return "sysv_abi";
   case CC_X86RegCall : return "regcall";
   case CC_AAPCS: return "aapcs";
   case CC_AAPCS_VFP: return "aapcs-vfp";
   case CC_AArch64VectorCall: return "aarch64_vector_pcs";
+  case CC_AArch64SVEPCS: return "aarch64_sve_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_SwiftAsync: return "swiftasynccall";
   case CC_PreserveMost: return "preserve_most";
   case CC_PreserveAll: return "preserve_all";
   }
bool AttributedType::isCallingConv() const {
   case attr::FastCall:
   case attr::StdCall:
   case attr::ThisCall:
   case attr::RegCall:
   case attr::SwiftCall:
   case attr::SwiftAsyncCall:
   case attr::VectorCall:
   case attr::AArch64VectorPcs:
+  case attr::AArch64SVEPcs:
   case attr::Pascal:
   case attr::MSABI:
   case attr::SysVABI:
   case attr::IntelOclBicc:
   case attr::PreserveMost:
   case attr::PreserveAll:
     return true;
   }

clang/lib/AST/TypePrinter.cpp

case CC_AAPCS:
       OS << " __attribute__((pcs(\"aapcs\")))";
       break;
     case CC_AAPCS_VFP:
       OS << " __attribute__((pcs(\"aapcs-vfp\")))";
       break;
     case CC_AArch64VectorCall:
       OS << "__attribute__((aarch64_vector_pcs))";
       break;
+    case CC_AArch64SVEPCS:
+      OS << "__attribute__((aarch64_sve_pcs))";
+      break;
     case CC_IntelOclBicc:
       OS << " __attribute__((intel_ocl_bicc))";
       break;
     case CC_Win64:
       OS << " __attribute__((ms_abi))";
       break;
     case CC_X86_64SysV:
       OS << " __attribute__((sysv_abi))";
#include "clang/Basic/AttrList.inc"
    while (!t->isFunctionType())
      t = t->getPointeeType();
    OS << (t->castAs<FunctionType>()->getCallConv() == CC_AAPCS ?
          "\"aapcs\"" : "\"aapcs-vfp\"");
    OS << ')';
    break;
   }
   case attr::AArch64VectorPcs: OS << "aarch64_vector_pcs"; break;
+  case attr::AArch64SVEPcs: OS << "aarch64_sve_pcs"; break;
   case attr::IntelOclBicc: OS << "inteloclbicc"; break;
   case attr::PreserveMost:
     OS << "preserve_most";
     break;
 
   case attr::PreserveAll:
     OS << "preserve_all";
     break;

clang/lib/Basic/Targets/AArch64.cpp

AArch64TargetInfo::checkCallingConvention(CallingConv CC) const {
   switch (CC) {
   case CC_C:
   case CC_Swift:
   case CC_SwiftAsync:
   case CC_PreserveMost:
   case CC_PreserveAll:
   case CC_OpenCLKernel:
   case CC_AArch64VectorCall:
+  case CC_AArch64SVEPCS:
   case CC_Win64:
     return CCCR_OK;
   default:
     return CCCR_Warning;
   }
 }
 
 bool AArch64TargetInfo::isCLZForZeroUndef() const { return false; }

clang/lib/CodeGen/CGCall.cpp

unsigned CodeGenTypes::ClangCallConvToLLVMCallConv(CallingConv CC) {
   case CC_AAPCS: return llvm::CallingConv::ARM_AAPCS;
   case CC_AAPCS_VFP: return llvm::CallingConv::ARM_AAPCS_VFP;
   case CC_IntelOclBicc: return llvm::CallingConv::Intel_OCL_BI;
   // TODO: Add support for __pascal to LLVM.
   case CC_X86Pascal: return llvm::CallingConv::C;
   // 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_AArch64SVEPCS: return llvm::CallingConv::AArch64_SVE_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_SwiftAsync: return llvm::CallingConv::SwiftTail;
   }
 }
if (D->hasAttr<PascalAttr>())
     return CC_X86Pascal;
 
   if (PcsAttr *PCS = D->getAttr<PcsAttr>())
     return (PCS->getPCS() == PcsAttr::AAPCS ? CC_AAPCS : CC_AAPCS_VFP);
 
   if (D->hasAttr<AArch64VectorPcsAttr>())
     return CC_AArch64VectorCall;
 
+  if (D->hasAttr<AArch64SVEPcsAttr>())
+    return CC_AArch64SVEPCS;
+
   if (D->hasAttr<IntelOclBiccAttr>())
     return CC_IntelOclBicc;
 
   if (D->hasAttr<MSABIAttr>())
     return IsWindows ? CC_C : CC_Win64;
 
   if (D->hasAttr<SysVABIAttr>())
     return IsWindows ? CC_X86_64SysV : CC_C;

clang/lib/CodeGen/CGDebugInfo.cpp

static unsigned getDwarfCC(CallingConv CC) {
   case CC_X86Pascal:
     return llvm::dwarf::DW_CC_BORLAND_pascal;
   case CC_Win64:
     return llvm::dwarf::DW_CC_LLVM_Win64;
   case CC_X86_64SysV:
     return llvm::dwarf::DW_CC_LLVM_X86_64SysV;
   case CC_AAPCS:
   case CC_AArch64VectorCall:
+  case CC_AArch64SVEPCS:
     return llvm::dwarf::DW_CC_LLVM_AAPCS;
   case CC_AAPCS_VFP:
     return llvm::dwarf::DW_CC_LLVM_AAPCS_VFP;
   case CC_IntelOclBicc:
     return llvm::dwarf::DW_CC_LLVM_IntelOclBicc;
   case CC_SpirFunction:
     return llvm::dwarf::DW_CC_LLVM_SpirFunction;
   case CC_OpenCLKernel:

clang/lib/Sema/SemaDeclAttr.cpp

case ParsedAttr::AT_Pcs: {
     }
 
     D->addAttr(::new (S.Context) PcsAttr(S.Context, AL, PCS));
     return;
   }
   case ParsedAttr::AT_AArch64VectorPcs:
     D->addAttr(::new (S.Context) AArch64VectorPcsAttr(S.Context, AL));
     return;
+  case ParsedAttr::AT_AArch64SVEPcs:
+    D->addAttr(::new (S.Context) AArch64SVEPcsAttr(S.Context, AL));
+    return;
   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));
case ParsedAttr::AT_SwiftAsyncCall:
     CC = CC_SwiftAsync;
     break;
   case ParsedAttr::AT_VectorCall:
     CC = CC_X86VectorCall;
     break;
   case ParsedAttr::AT_AArch64VectorPcs:
     CC = CC_AArch64VectorCall;
     break;
+  case ParsedAttr::AT_AArch64SVEPcs:
+    CC = CC_AArch64SVEPCS;
+    break;
   case ParsedAttr::AT_RegCall:
     CC = CC_X86RegCall;
     break;
   case ParsedAttr::AT_MSABI:
     CC = Context.getTargetInfo().getTriple().isOSWindows() ? CC_C :
                                                              CC_Win64;
     break;
   case ParsedAttr::AT_SysVABI:
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_AArch64SVEPcs:
     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_StdCall:                                                 \
   case ParsedAttr::AT_ThisCall:                                                \
   case ParsedAttr::AT_RegCall:                                                 \
   case ParsedAttr::AT_Pascal:                                                  \
   case ParsedAttr::AT_SwiftCall:                                               \
   case ParsedAttr::AT_SwiftAsyncCall:                                          \
   case ParsedAttr::AT_VectorCall:                                              \
   case ParsedAttr::AT_AArch64VectorPcs:                                        \
+  case ParsedAttr::AT_AArch64SVEPcs:                                           \
   case ParsedAttr::AT_MSABI:                                                   \
   case ParsedAttr::AT_SysVABI:                                                 \
   case ParsedAttr::AT_Pcs:                                                     \
   case ParsedAttr::AT_IntelOclBicc:                                            \
   case ParsedAttr::AT_PreserveMost:                                            \
   case ParsedAttr::AT_PreserveAll
 
 // Function type attributes.
static Attr *getCCTypeAttr(ASTContext &Ctx, ParsedAttr &Attr) {
   case ParsedAttr::AT_SwiftCall:
     return createSimpleAttr<SwiftCallAttr>(Ctx, Attr);
   case ParsedAttr::AT_SwiftAsyncCall:
     return createSimpleAttr<SwiftAsyncCallAttr>(Ctx, Attr);
   case ParsedAttr::AT_VectorCall:
     return createSimpleAttr<VectorCallAttr>(Ctx, Attr);
   case ParsedAttr::AT_AArch64VectorPcs:
     return createSimpleAttr<AArch64VectorPcsAttr>(Ctx, Attr);
+  case ParsedAttr::AT_AArch64SVEPcs:
+    return createSimpleAttr<AArch64SVEPcsAttr>(Ctx, Attr);
   case ParsedAttr::AT_Pcs: {
     // The attribute may have had a fixit applied where we treated an
     // identifier as a string literal.  The contents of the string are valid,
     // but the form may not be.
     StringRef Str;
     if (Attr.isArgExpr(0))
       Str = cast<StringLiteral>(Attr.getArgAsExpr(0))->getString();
     else

clang/test/CodeGen/aarch64-svepcs.c

+// RUN: %clang_cc1 -triple aarch64-linux-gnu -emit-llvm -o - %s | FileCheck %s -check-prefix=CHECKC
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -emit-llvm -x c++ -o - %s | FileCheck %s -check-prefix=CHECKCXX
+// RUN: %clang_cc1 -triple i686-pc-linux-gnu -verify %s
+
+void __attribute__((aarch64_sve_pcs)) f(int *); // expected-warning {{'aarch64_sve_pcs' calling convention is not supported for this target}}
+
+// CHECKC: define{{.*}} void @g(
+// CHECKCXX: define{{.*}} void @_Z1gPi(
+void g(int *a) {
+
+  // CHECKC: call aarch64_sve_vector_pcs void @f(
+  // CHECKCXX: call aarch64_sve_vector_pcs void @_Z1fPi
+  f(a);
+}
+
+// CHECKC: declare aarch64_sve_vector_pcs void @f(
+// CHECKCXX: declare aarch64_sve_vector_pcs void @_Z1fPi
+
+void __attribute__((aarch64_sve_pcs)) h(int *a) { // expected-warning {{'aarch64_sve_pcs' calling convention is not supported for this target}}
+                                                  // CHECKC: define{{.*}} aarch64_sve_vector_pcs void @h(
+                                                  // CHECKCXX: define{{.*}} aarch64_sve_vector_pcs void @_Z1hPi(
+  f(a);
+}

clang/test/Sema/aarch64-svepcs.c

+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +sve -verify %s
+
+typedef __attribute__((aarch64_sve_pcs)) int invalid_typedef; // expected-warning {{'aarch64_sve_pcs' only applies to function types; type here is 'int'}}
+
+void __attribute__((aarch64_sve_pcs(0))) foo0(void); // expected-error {{'aarch64_sve_pcs' attribute takes no arguments}}
+
+void __attribute__((aarch64_sve_pcs, preserve_all)) foo1(void); // expected-error {{not compatible}}
+
+void __attribute__((cdecl)) foo2(void);             // expected-note {{previous declaration is here}}
+void __attribute__((aarch64_sve_pcs)) foo2(void) {} // expected-error {{function declared 'aarch64_sve_pcs' here was previously declared 'cdecl'}}
+
+void foo3(void);                                    // expected-note {{previous declaration is here}}
+void __attribute__((aarch64_sve_pcs)) foo3(void) {} // expected-error {{function declared 'aarch64_sve_pcs' here was previously declared without calling convention}}
+
+typedef int (*fn_ty)(void);
+typedef int __attribute__((aarch64_sve_pcs)) (*aasvepcs_fn_ty)(void);
+void foo4(fn_ty ptr1, aasvepcs_fn_ty ptr2) {
+  ptr1 = ptr2; // expected-warning {{incompatible function pointer types}}
+}

clang/test/Sema/callingconv.c

int __attribute__((pcs(pcs1))) pcs3(void); // expected-error {{'pcs' attribute requires a string}} \
                                            // expected-error {{invalid PCS type}}
 int __attribute__((pcs(0))) pcs4(void); // expected-error {{'pcs' attribute requires a string}}
 /* These are ignored because the target is i386 and not ARM */
 int __attribute__((pcs("aapcs"))) pcs5(void); // expected-warning {{'pcs' calling convention is not supported for this target}}
 int __attribute__((pcs("aapcs-vfp"))) pcs6(void); // expected-warning {{'pcs' calling convention is not supported for this target}}
 int __attribute__((pcs("foo"))) pcs7(void); // expected-error {{invalid PCS type}}
 
 int __attribute__((aarch64_vector_pcs)) aavpcs(void); // expected-warning {{'aarch64_vector_pcs' calling convention is not supported for this target}}
+int __attribute__((aarch64_sve_pcs)) aasvepcs(void);  // expected-warning {{'aarch64_sve_pcs' calling convention is not supported for this target}}
 
 // PR6361
 void ctest3();
 void __attribute__((cdecl)) ctest3() {}
 
 // PR6408
 typedef __attribute__((stdcall)) void (*PROC)();
 PROC __attribute__((cdecl)) ctest4(const char *x) {}

clang/tools/libclang/CXType.cpp

switch (FD->getCallConv()) {
       TCALLINGCONV(C);
       TCALLINGCONV(X86StdCall);
       TCALLINGCONV(X86FastCall);
       TCALLINGCONV(X86ThisCall);
       TCALLINGCONV(X86Pascal);
       TCALLINGCONV(X86RegCall);
       TCALLINGCONV(X86VectorCall);
       TCALLINGCONV(AArch64VectorCall);
+      TCALLINGCONV(AArch64SVEPCS);
       TCALLINGCONV(Win64);
       TCALLINGCONV(X86_64SysV);
       TCALLINGCONV(AAPCS);
       TCALLINGCONV(AAPCS_VFP);
       TCALLINGCONV(IntelOclBicc);
       TCALLINGCONV(Swift);
       TCALLINGCONV(SwiftAsync);
       TCALLINGCONV(PreserveMost);