Set calling convention for CUDA kernel

[yaxunl]

Summary

This patch sets target specific calling convention for CUDA kernels in IR.

Patch by Greg Rodgers.
Modified and lit test added by Yaxun Liu.

[rjmccall]

Is there a reason for this to be done as a special case in IRGen instead of just implicitly applying the calling convention in Sema?

[yaxunl]

Upload diff with full context.

[yaxunl]

In D44747#1044893, @rjmccall wrote:

Is there a reason for this to be done as a special case in IRGen instead of just implicitly applying the calling convention in Sema?

The calling convention is not used in Sema, therefore it seems simpler to do it in codegen. I could try doing this in Sema too. Is there any advantage of doing this in Sema?

Thanks.

[rjmccall]

In D44747#1044916, @yaxunl wrote:

In D44747#1044893, @rjmccall wrote:

Is there a reason for this to be done as a special case in IRGen instead of just implicitly applying the calling convention in Sema?

The calling convention is not used in Sema, therefore it seems simpler to do it in codegen. I could try doing this in Sema too. Is there any advantage of doing this in Sema?

In IRGen, it's a special case for your specific language mode on your specific target. In Sema, it can be done as part of the special checking for kernel functions.

Also, it looks like CUDA allows you to take the address of a __global__ function, and indirect calls to such functions presumably still follow the normal CUDA restrictions, so there must be *some* reflection of this in Sema.

[yaxunl]

Revised by John's comments. Introduce CC_CUDAKernel calling convention in AST, which is translated to target calling convention in IR.

[rjmccall]

lib/AST/Type.cpp

2762 ↗

(On Diff #139625)

For consistency with the rest of this switch, please put the return on the same line as its case.

lib/AST/TypePrinter.cpp

781 ↗

(On Diff #139625)

I think the spelling for this is __global__. You might need to adjust printing because this isn't the right place to print it, of course.

lib/CodeGen/CGCall.cpp

68 ↗

(On Diff #139625)

For consistency with the rest of this switch, please put the return on the same line as its case.

lib/Sema/SemaOverload.cpp

1492 ↗

(On Diff #139625)

It's cheaper not to check the CUDA language mode here; pulling the CC out of the FPT is easy.

Why is this necessary, anyway? From the spec, it doesn't look to me like kernel function pointers can be converted to ordinary function pointers. A kernel function pointer is supposed to be declared with something like __global__ void (*fn)(void). You'll need to change your patch to SemaType to apply the CC even when compiling for the host, of course.

I was going to say that you should use this CC in your validation that calls with execution configurations go to kernel functions, but... I can't actually find where you do that validation.

Do you need these function pointers to be a different size from the host function pointer?

tools/libclang/CXType.cpp

630 ↗

(On Diff #139625)

Formatting.

[yaxunl]

lib/Sema/SemaOverload.cpp

1492 ↗

(On Diff #139625)

In CUDA, __global__ can only be used with function declaration or definition. Using it in function pointer declaration will result in a warning: 'global' attribute only applies to functions.

Also, there is this lit test in SemaCUDA:

__global__ void kernel() {}

typedef void (*fn_ptr_t)();

__host__ fn_ptr_t get_ptr_h() {
  return kernel;
}

It allows implicit conversion of __global__ void() to void(*)(), therefore I need the above change to drop the CUDA kernel calling convention in such implicit conversion.

[rjmccall]

lib/Sema/SemaOverload.cpp

1492 ↗

(On Diff #139625)

I see. I must have mis-read the specification, but I see that the code samples I can find online agree with that test case. So __global__ function pointers are just treated as function pointers, and it's simply undefined behavior if you try to call a function pointer that happens to be a kernel without an execution configuration, or contrariwise if you use an execution configuration to call a function pointer that isn't a kernel.

In that case, I think the best solution is to just immediately strip __global__ from the type of a DRE to a kernel function, since __global__ isn't supposed to be part of the user-facing type system.

[yaxunl]

Revised by John's comments. Drop CUDA kernel calling convention in DRE.

[rjmccall]

LGTM.

If __global__ is supported in C++ structures, you might also need to make sure that member function constants (&A::kernel_function) drop the CC. And it might be a good idea to make sure that decltype(kernel_function) doesn't have a problem with it, either, since that does do some special-case work.

lib/Sema/SemaExpr.cpp

1669 ↗

(On Diff #140076)

You should use getAs<FunctionType> here (no const necessary). It's possible to declare a function with a typedef of function type, you just can't define it that way.

[yaxunl]

Matt, are you OK with the change from amdgcn backend point of view? Thanks.

lib/Sema/SemaExpr.cpp

1669 ↗

(On Diff #140076)

will do.

[yaxunl]

Use getAs instead of dyn_cast as John suggested.

[rjmccall]

LGTM.

[tra]

lib/Sema/SemaType.cpp

3319–3330 ↗

(On Diff #140257)

This apparently breaks compilation of some CUDA code in our internal tests. I'm working on minimizing a reproduction case. Should this code be enabled for AMD GPUs only?

[tra]

lib/Sema/SemaType.cpp

3319–3330 ↗

(On Diff #140257)

Here's a small snippet of code that previously used to compile and work:

template <typename T>
__global__ void EmptyKernel(void) { }

struct Dummy {
  /// Type definition of the EmptyKernel kernel entry point
  typedef void (*EmptyKernelPtr)();
  EmptyKernelPtr Empty() { return EmptyKernel<void>; }
};

AFAICT, it's currently impossible to apply global to pointers, so there's no way to make the code above work with this patch applied.

[yaxunl]

I will try fixing that.

The CUDA kernel calling convention should be dropped in all DRE's since it is invisible to the user.

Sam

[tra]

In D44747#1055877, @yaxunl wrote:

I will try fixing that.

The CUDA kernel calling convention should be dropped in all DRE's since it is invisible to the user.

Sam

Apparently it's not always the case.
Here's a bit more elaborate example demonstrating inconsistency in this behavior. Calling convention is ignored for regular functions, but not for function templates.

__global__ void EmptyKernel(void) { }

template <typename T>
__global__ void EmptyKernelT(void) { }

struct Dummy {
  /// Type definition of the EmptyKernel kernel entry point
  typedef void (*EmptyKernelPtr)();
  EmptyKernelPtr Empty() { return EmptyKernel; } // this one works
  EmptyKernelPtr EmptyT() { return EmptyKernelT<void>; } // this one errors out.
};

Do you think this is something you can fix quickly or do you want to unroll the change while you figure out what's going on?

[yaxunl]

Let's revert it for now. I will create a review after fixing it and commit it again with the fix.

Thanks.

Sam

[tra]

In D44747#1055894, @yaxunl wrote:

Let's revert it for now. I will create a review after fixing it and commit it again with the fix.

Thanks.

Sam

reverted in r329099.

lib/CodeGen/CodeGenModule.cpp

   auto *Fn = cast<llvm::Function>(GV);
   setFunctionLinkage(GD, Fn);
 
   // FIXME: this is redundant with part of setFunctionDefinitionAttributes
   setGVProperties(Fn, GD);
 
   MaybeHandleStaticInExternC(D, Fn);
 
+  if ((getTriple().getArch() == llvm::Triple::amdgcn) &&
+      D->hasAttr<CUDAGlobalAttr>())
+    Fn->setCallingConv(llvm::CallingConv::AMDGPU_KERNEL);
   maybeSetTrivialComdat(*D, *Fn);
 
   CodeGenFunction(*this).GenerateCode(D, Fn, FI);
 
   setNonAliasAttributes(GD, Fn);
   SetLLVMFunctionAttributesForDefinition(D, Fn);
 
   if (const ConstructorAttr *CA = D->getAttr<ConstructorAttr>())

test/CodeGenCUDA/kernel-amdgcn.cu

+// RUN: %clang_cc1 -triple amdgcn -fcuda-is-device -emit-llvm %s -o - | FileCheck %s
+#include "Inputs/cuda.h"
+
+// CHECK: define amdgpu_kernel void @_ZN1A6kernelEv()
+class A {
+public:
+  static __global__ void kernel(){}
+};
+
+// CHECK: define void @_Z10non_kernelv()
+__device__ void non_kernel(){}
+
+// CHECK: define amdgpu_kernel void @_Z6kerneli(i32 %x)
+__global__ void kernel(int x) {
+  non_kernel();
+}
+
+// CHECK: define amdgpu_kernel void @_Z15template_kernelI1AEvT_()
+template<class T>
+__global__ void template_kernel(T x) {}
+
+void launch(void *f);
+
+int main() {
+  launch((void*)A::kernel);
+  launch((void*)kernel);
+  launch((void*)template_kernel<A>);
+  return 0;
+}