[amdgpu] Add amdgpu_kernel calling conv attribute to clang

[JonChesterfield]

Summary

Allows emitting define amdgpu_kernel void @func() IR from C or C++.

This replaces the current workflow which is to write a stub in opencl that
calls an external C function implemented in C++ combined through llvm-link.

Calling the resulting function still requires a manual implementation of the
ABI from the host side. The primary application is for more rapid debugging
of the amdgpu backend by permuting a C or C++ test file instead of manually
updating an IR file.

Implementation closely follows D54425. Non-amd reviewers from there.

[yaxunl]

need a codegen test to make sure amdgpu_kernel ABI is used in C/C++ for functions with this attribute. https://github.com/llvm/llvm-project/blob/main/clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu#L64 may be used as an example.

[JonChesterfield]

In D125970#3525985, @yaxunl wrote:

need a codegen test to make sure amdgpu_kernel ABI is used in C/C++ for functions with this attribute

We've already got tests that check the amdgpu_kernel calling conv is lowered correctly. This change only adds it to clang, so checking the IR seems sufficient. I can copy/paste/mod that test case if you like, but it doesn't give any extra coverage that I can see

[yaxunl]

In D125970#3526053, @JonChesterfield wrote:

In D125970#3525985, @yaxunl wrote:

need a codegen test to make sure amdgpu_kernel ABI is used in C/C++ for functions with this attribute

We've already got tests that check the amdgpu_kernel calling conv is lowered correctly. This change only adds it to clang, so checking the IR seems sufficient. I can copy/paste/mod that test case if you like, but it doesn't give any extra coverage that I can see

we only need an IR test, e.g. check struct type kernel arg is using byref.

[JonChesterfield]

OK, so that's a different thing. CUDA/HIP has a bunch of rules about implicitly tagging things with addrspace(1) at the call boundary. I don't think any of that magic should exist for C or C++, the developer gets to spell out the address space stuff they want explicitly, and if they want to link it against CUDA/HIP/OpenMP code they get to look up the rules. In particular, persuading clang to do the extra argument mangling stuff will get in the way of using this to create test cases.

I'm writing the corresponding test case for that now. I only really wanted void func(void) to be usable from this, with the assumption that the developer digs arguments out of the kernarg pointer if they want some.

Found something weird. The cuda test case above compiles with O0 and also with O2.

__attribute__((amdgpu_kernel)) void kernel1(int *x) {
  x[0]++;
}

On O0, the argument is in no particular address space, as specified.

; Function Attrs: mustprogress noinline nounwind optnone
define dso_local amdgpu_kernel void @_Z7kernel1Pi(i32* noundef %x) #0 {
entry:
  %x.addr = alloca i32*, align 8, addrspace(5)
  %x.addr.ascast = addrspacecast i32* addrspace(5)* %x.addr to i32**
  store i32* %x, i32** %x.addr.ascast, align 8
  %0 = load i32*, i32** %x.addr.ascast, align 8
  %arrayidx = getelementptr inbounds i32, i32* %0, i64 0
  %1 = load i32, i32* %arrayidx, align 4
  %inc = add nsw i32 %1, 1
  store i32 %inc, i32* %arrayidx, align 4
  ret void
}

After opt O2, we cast the address to addrspace(1), then dereference that.

define dso_local amdgpu_kernel void @_Z7kernel1Pi(i32* nocapture noundef %x) local_unnamed_addr #0 {
entry:
  %x.global = addrspacecast i32* %x to i32 addrspace(1)*
  %0 = load i32, i32 addrspace(1)* %x.global, align 4, !amdgpu.noclobber !2
  %inc = add nsw i32 %0, 1
  store i32 %inc, i32 addrspace(1)* %x.global, align 4
  ret void
}

So that's a bug, right? An optimisation has decided an unadorned pointer argument can be assumed to be in addrspace(1)

[JonChesterfield]

• Add O0 arg passing codegen test

[JonChesterfield]

Added a codegen test for arg passing. It establishes that most arguments are left alone, but structs passed by value are handled as an addrspace(4) byref. Letting opt -O2 run annotated some argument pointers as being in addrspace(1) which I think is wrong.

I have no judgement to pass on the current codegen for this - it might be correct, or we might have bugs in opt - but those bugs are exactly those that are easier to flush out if we land this patch first. All I want to achieve with this patch is a means of tagging a void func(void) with the calling convention.

If we wanted to go further - and turn C++ into a language that is robustly usable on the GPU - I think we have a bunch of tasks related to handling addrspace annotations to burn through.

[yaxunl]

LGTM. Thanks.

[JonChesterfield]

Thanks for accepting! I'm interested to learn more about how the calling conv works, e.g. if parts of it are implemented in clang and parts of it patched on the fly by opt, but that's downstream of easy access to writing C tests that use it.

[JonChesterfield]

• Rebase on main

[JonChesterfield]

• Fix git merge misfires

[JonChesterfield]

• Fix git merge misfires

[JonChesterfield]

Unintentionally created this patch against an older version of main and it interacted badly with D124998 on the rebase. Rerunning tests now, and will leave this open for further comments for a little while. Thanks all

[JonChesterfield]

A clangd buildbot (https://lab.llvm.org/buildbot/#/builders/131/builds/27770) failed on this with

[ RUN      ] SerializationTest.NoCrashOnBadArraySize
==384111==ERROR: ThreadSanitizer failed to allocate 0x10000 (65536) bytes of stack depot (error code: 12)
ERROR: Failed to mmap

I believe this is coincidence

edit: confirmed, earlier builds failed the same way, e.g. https://lab.llvm.org/buildbot/#/builders/131/builds/27768

[aaron.ballman]

The primary application is for more rapid debugging of the amdgpu backend by permuting a C or C++ test file instead of manually updating an IR file.

Given that this is adding a calling convention, which has significant impacts on our type system: is this use case important enough to steal a bit for this CC? This sounds *super* special case to me, but maybe it's a common need?

clang/include/clang/Basic/Attr.td

1862

No new undocumented attributes.

[aaron.ballman]

In D125970#3527624, @aaron.ballman wrote:

The primary application is for more rapid debugging of the amdgpu backend by permuting a C or C++ test file instead of manually updating an IR file.

Given that this is adding a calling convention, which has significant impacts on our type system: is this use case important enough to steal a bit for this CC? This sounds *super* special case to me, but maybe it's a common need?

Btw, I'd appreciate if you gave code reviewers more than one day to review a change to the type system before landing -- I'm in WG14 meetings all week, so I don't have much time to do a thorough review of something like this.

[JonChesterfield]

If it was adding a calling convention, sure - caution warranted. There's no llvm change here though, an existing CC is exposed to C++. No change to the type system either.

I'll propose a patch with some documentation for it if you wish, but it'll just say "For ad hoc debugging of the amdgpu backend". Undocumented seems to state that more clearly.

[aaron.ballman]

In D125970#3527685, @JonChesterfield wrote:

If it was adding a calling convention, sure - caution warranted. There's no llvm change here though, an existing CC is exposed to C++. No change to the type system either.

This is adding a user-facing calling convention to Clang and it changes the type system as a result. For example, lambda function pointer conversion operators sometimes are generated for each calling convention so that you can form a function pointer of the correct type (this might not be impacted by your change here); there's a specific number of bits for representing the enumeration of calling conventions and this uses one of those bits, etc.

I'll propose a patch with some documentation for it if you wish, but it'll just say "For ad hoc debugging of the amdgpu backend". Undocumented seems to state that more clearly.

I continue to question whether we want to support such a calling convention. This does not seem to be generally useful enough to warrant inclusion in Clang. The fact that you'd like to leave it undocumented as that's more clear for users is a pretty good indication that this calling convention doesn't meet the bar for an extension.

[JonChesterfield]

In D125970#3531645, @aaron.ballman wrote:

In D125970#3527685, @JonChesterfield wrote:

If it was adding a calling convention, sure - caution warranted. There's no llvm change here though, an existing CC is exposed to C++. No change to the type system either.

This is adding a user-facing calling convention to Clang and it changes the type system as a result. For example, lambda function pointer conversion operators sometimes are generated for each calling convention so that you can form a function pointer of the correct type (this might not be impacted by your change here); there's a specific number of bits for representing the enumeration of calling conventions and this uses one of those bits, etc.

It slightly changes the type system of C++ code in that the calling convention was previously only available in opencl / openmp etc. I was under the impression that the compiler data representation cost of calling conventions was in LLVM and thus pre-paid for the calling convention this gives access to. There's the enum CallingConv which has gained a field, I didn't realise that was input into something of limited bitwidth.

I'll propose a patch with some documentation for it if you wish, but it'll just say "For ad hoc debugging of the amdgpu backend". Undocumented seems to state that more clearly.

I continue to question whether we want to support such a calling convention. This does not seem to be generally useful enough to warrant inclusion in Clang. The fact that you'd like to leave it undocumented as that's more clear for users is a pretty good indication that this calling convention doesn't meet the bar for an extension.

Strictly speaking this lets people write a GPU kernel that can execute on AMDGPU in freestanding C++. I happen to want to do that for testing LLVM in the immediate instance but there's arguably wider applicability. However, it looks like how arguments are represented in this calling convention has some strangeness (see discussion with Sam above), particularly with regard to address spaces.

I can revert this patch if necessary, but it'll force me to continue trying to test our compiler through the lens of opencl, and rules out programming the hardware without the various specific language front ends. I think that would be a sad loss.

[aaron.ballman]

In D125970#3531673, @JonChesterfield wrote:

In D125970#3531645, @aaron.ballman wrote:

In D125970#3527685, @JonChesterfield wrote:

If it was adding a calling convention, sure - caution warranted. There's no llvm change here though, an existing CC is exposed to C++. No change to the type system either.

This is adding a user-facing calling convention to Clang and it changes the type system as a result. For example, lambda function pointer conversion operators sometimes are generated for each calling convention so that you can form a function pointer of the correct type (this might not be impacted by your change here); there's a specific number of bits for representing the enumeration of calling conventions and this uses one of those bits, etc.

It slightly changes the type system of C++ code in that the calling convention was previously only available in opencl / openmp etc. I was under the impression that the compiler data representation cost of calling conventions was in LLVM and thus pre-paid for the calling convention this gives access to. There's the enum CallingConv which has gained a field, I didn't realise that was input into something of limited bitwidth.

Calling conventions are weird in that they have a fair amount of frontend AND backend work involved with them (though maybe this one is more backend than frontend as it doesn't seem to be doing much different in codegen). As for the bit-width thing, it mostly comes into play here: https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/Type.h#L3678 -- we try to pack as much information into as few bits as possible because Type overhead causes big problems (for example, it limits template instantiation depth due to memory overhead). We have *some* wiggle room left in that bit-field, and we have some ideas on how to improve the situation, but... nobody's done the refactoring work yet and each new calling convention we add brings us that much closer to the answer being "sorry, can't do it.".

I'll propose a patch with some documentation for it if you wish, but it'll just say "For ad hoc debugging of the amdgpu backend". Undocumented seems to state that more clearly.

I continue to question whether we want to support such a calling convention. This does not seem to be generally useful enough to warrant inclusion in Clang. The fact that you'd like to leave it undocumented as that's more clear for users is a pretty good indication that this calling convention doesn't meet the bar for an extension.

Strictly speaking this lets people write a GPU kernel that can execute on AMDGPU in freestanding C++.

That sounds generally useful, which is great!

I happen to want to do that for testing LLVM in the immediate instance but there's arguably wider applicability. However, it looks like how arguments are represented in this calling convention has some strangeness (see discussion with Sam above), particularly with regard to address spaces.

That sounds less great. :-( This suggests there may be another calling convention in the future which corrects those deficiencies.

I can revert this patch if necessary, but it'll force me to continue trying to test our compiler through the lens of opencl, and rules out programming the hardware without the various specific language front ends. I think that would be a sad loss.

My thinking is: I don't want you to revert and have no solution, because you have a problem to solve and this (presumably) solves it for you. But at the same time, I'd like us to be able to explore options to make sure that a calling convention is the best approach and that we're confident that we won't need additional calling conventions to fix corner cases in the future. For example, can the calling convention be inferred at codegen time in Clang or by an LLVM pass so that the FE doesn't need to expose an attribute through the type system?

Have you explored alternatives that don't require a user-facing attribute?

[yaxunl]

In HIP, kernels are represented by attribute global and not by calling convention in clang. This may be an alternative.

Another alternative might be merging amdgpu_kernel and opencl_kernel calling convention since for the same target they are the same. They could be represented by the same kernel calling convention in AST.

clang/include/clang/Basic/Attr.td

 
 def AMDGPUNumVGPR : InheritableAttr {
   let Spellings = [Clang<"amdgpu_num_vgpr", 0>];
   let Args = [UnsignedArgument<"NumVGPR">];
   let Documentation = [AMDGPUNumSGPRNumVGPRDocs];
   let Subjects = SubjectList<[Function], ErrorDiag, "kernel functions">;
 }
 
+def AMDGPUKernelCall : DeclOrTypeAttr {
+  let Spellings = [Clang<"amdgpu_kernel">];
+  let Documentation = [Undocumented];
+}
+
 def BPFPreserveAccessIndex : InheritableAttr,
                              TargetSpecificAttr<TargetBPF>  {
   let Spellings = [Clang<"preserve_access_index">];
   let Subjects = SubjectList<[Record], ErrorDiag>;
   let Documentation = [BPFPreserveAccessIndexDocs];
   let LangOpts = [COnly];
 }
 

clang/include/clang/Basic/Specifiers.h

enum CallingConv {
     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))
+    CC_AMDGPUKernelCall, // __attribute__((amdgpu_kernel))
   };
 
   /// 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_X86VectorCall:
   case CC_X86Pascal:
   case CC_X86RegCall:
   case CC_AAPCS:
   case CC_AAPCS_VFP:
   case CC_AArch64VectorCall:
   case CC_AArch64SVEPCS:
+  case CC_AMDGPUKernelCall:
   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_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_AMDGPUKernelCall: return "amdgpu_kernel";
   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::StdCall:
   case attr::ThisCall:
   case attr::RegCall:
   case attr::SwiftCall:
   case attr::SwiftAsyncCall:
   case attr::VectorCall:
   case attr::AArch64VectorPcs:
   case attr::AArch64SVEPcs:
+  case attr::AMDGPUKernelCall:
   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_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_AMDGPUKernelCall:
+      OS << "__attribute__((amdgpu_kernel))";
+      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))";
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::AMDGPUKernelCall: OS << "amdgpu_kernel"; 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/AMDGPU.h

public:
   }
 
   CallingConvCheckResult checkCallingConvention(CallingConv CC) const override {
     switch (CC) {
     default:
       return CCCR_Warning;
     case CC_C:
     case CC_OpenCLKernel:
+    case CC_AMDGPUKernelCall:
       return CCCR_OK;
     }
   }
 
   // In amdgcn target the null pointer in global, constant, and generic
   // address space has value 0 but in private and local address space has
   // value ~0.
   uint64_t getNullPointerValue(LangAS AS) const override {

clang/lib/CodeGen/CGCall.cpp

unsigned CodeGenTypes::ClangCallConvToLLVMCallConv(CallingConv CC) {
   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_AMDGPUKernelCall: return llvm::CallingConv::AMDGPU_KERNEL;
   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 (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<AMDGPUKernelCallAttr>())
+    return CC_AMDGPUKernelCall;
+
   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

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:
+  case CC_AMDGPUKernelCall:
     return llvm::dwarf::DW_CC_LLVM_OpenCLKernel;
   case CC_Swift:
     return llvm::dwarf::DW_CC_LLVM_Swift;
   case CC_SwiftAsync:
     // [FIXME: swiftasynccc] Update to SwiftAsync once LLVM support lands.
     return llvm::dwarf::DW_CC_LLVM_Swift;
   case CC_PreserveMost:
     return llvm::dwarf::DW_CC_LLVM_PreserveMost;

clang/lib/Sema/SemaDeclAttr.cpp

case ParsedAttr::AT_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_AMDGPUKernelCall:
+    D->addAttr(::new (S.Context) AMDGPUKernelCallAttr(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_VectorCall:
     CC = CC_X86VectorCall;
     break;
   case ParsedAttr::AT_AArch64VectorPcs:
     CC = CC_AArch64VectorCall;
     break;
   case ParsedAttr::AT_AArch64SVEPcs:
     CC = CC_AArch64SVEPCS;
     break;
+  case ParsedAttr::AT_AMDGPUKernelCall:
+    CC = CC_AMDGPUKernelCall;
+    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_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:
+  case ParsedAttr::AT_AMDGPUKernelCall:
     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_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_AMDGPUKernelCall:                                        \
   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_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_AMDGPUKernelCall:
+    return createSimpleAttr<AMDGPUKernelCallAttr>(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/CodeGenCXX/amdgpu-kernel-arg-pointer-type.cpp

+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang_cc1 -no-opaque-pointers -triple amdgcn-amd-amdhsa -emit-llvm %s -o - | FileCheck --check-prefixes=COMMON,CHECK %s
+
+// Derived from CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu by deleting references to HOST
+// The original test passes the result through opt O2, but that seems to introduce invalid
+// addrspace casts which are not being fixed as part of the present change.
+
+// COMMON-LABEL: define{{.*}} amdgpu_kernel void @_Z7kernel1Pi(i32* {{.*}} %x)
+// CHECK-NOT: ={{.*}} addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
+__attribute__((amdgpu_kernel)) void kernel1(int *x) {
+  x[0]++;
+}
+
+// COMMON-LABEL: define{{.*}} amdgpu_kernel void @_Z7kernel2Ri(i32* {{.*}} nonnull align 4 dereferenceable(4) %x)
+// CHECK-NOT: ={{.*}} addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
+__attribute__((amdgpu_kernel)) void kernel2(int &x) {
+  x++;
+}
+
+// CHECK-LABEL: define{{.*}} amdgpu_kernel void  @_Z7kernel3PU3AS2iPU3AS1i(i32 addrspace(2)*{{.*}} %x, i32 addrspace(1)*{{.*}} %y)
+// CHECK-NOT: ={{.*}} addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
+__attribute__((amdgpu_kernel)) void kernel3(__attribute__((address_space(2))) int *x,
+                                            __attribute__((address_space(1))) int *y) {
+  y[0] = x[0];
+}
+
+// COMMON-LABEL: define{{.*}} void @_Z4funcPi(i32*{{.*}} %x)
+// CHECK-NOT: ={{.*}} addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
+__attribute__((amdgpu_kernel)) void func(int *x) {
+  x[0]++;
+}
+
+struct S {
+  int *x;
+  float *y;
+};
+// `by-val` struct is passed by-indirect-alias (a mix of by-ref and indirect
+// by-val). However, the enhanced address inferring pass should be able to
+// assume they are global pointers.
+//
+
+// COMMON-LABEL: define{{.*}} amdgpu_kernel void @_Z7kernel41S(%struct.S addrspace(4)*{{.*}} byref(%struct.S) align 8 %0)
+__attribute__((amdgpu_kernel)) void kernel4(struct S s) {
+  s.x[0]++;
+  s.y[0] += 1.f;
+}
+
+// COMMON-LABEL: define{{.*}} amdgpu_kernel void @_Z7kernel5P1S(%struct.S* {{.*}} %s)
+__attribute__((amdgpu_kernel)) void kernel5(struct S *s) {
+  s->x[0]++;
+  s->y[0] += 1.f;
+}
+
+struct T {
+  float *x[2];
+};
+// `by-val` array is passed by-indirect-alias (a mix of by-ref and indirect
+// by-val). However, the enhanced address inferring pass should be able to
+// assume they are global pointers.
+//
+// COMMON-LABEL: define{{.*}} amdgpu_kernel void @_Z7kernel61T(%struct.T addrspace(4)*{{.*}} byref(%struct.T) align 8 %0)
+__attribute__((amdgpu_kernel)) void kernel6(struct T t) {
+  t.x[0][0] += 1.f;
+  t.x[1][0] += 2.f;
+}
+
+// Check that coerced pointers retain the noalias attribute when qualified with __restrict.
+// COMMON-LABEL: define{{.*}} amdgpu_kernel void @_Z7kernel7Pi(i32* noalias{{.*}} %x)
+__attribute__((amdgpu_kernel)) void kernel7(int *__restrict x) {
+  x[0]++;
+}
+
+// Single element struct.
+struct SS {
+  float *x;
+};
+// COMMON-LABEL: define{{.*}} amdgpu_kernel void @_Z7kernel82SS(float* %a.coerce)
+// CHECK-NOT: ={{.*}} addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
+__attribute__((amdgpu_kernel)) void kernel8(struct SS a) {
+  *a.x += 3.f;
+}
+

clang/test/Sema/callingconv.c

 /* 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}}
 
+int __attribute__((amdgpu_kernel)) amdgpu_kernel(void); // expected-warning {{'amdgpu_kernel' 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(AAPCS);
       TCALLINGCONV(AAPCS_VFP);
       TCALLINGCONV(IntelOclBicc);
       TCALLINGCONV(Swift);
       TCALLINGCONV(SwiftAsync);
       TCALLINGCONV(PreserveMost);
       TCALLINGCONV(PreserveAll);
     case CC_SpirFunction: return CXCallingConv_Unexposed;
+    case CC_AMDGPUKernelCall: return CXCallingConv_Unexposed;
     case CC_OpenCLKernel: return CXCallingConv_Unexposed;
       break;
     }
 #undef TCALLINGCONV
   }
   
   return CXCallingConv_Invalid;
 }