================
@@ -5206,7 +5206,8 @@ static void handleCallConvAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
static void handleDeviceKernelAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
const auto *FD = dyn_cast_or_null<FunctionDecl>(D);
bool IsFunctionTemplate = FD && FD->getDescribedFunctionTemplate();
- if (S.getASTContext().getTargetInfo().getTriple().isNVPTX()) {
+ if (S.getASTContext().getTargetInfo().getTriple().isNVPTX() &&
+ !DeviceKernelAttr::isOpenCLSpelling(AL)) {
handleGlobalAttr(S, D, AL);
} else {
----------------
tahonermann wrote:
That branching is exactly my concern; it doesn't make sense to assume OpenCL
semantics are intended for a non-OpenCL spelling and a non-NVPTX target. The
branch that calls `handleGlobalAttr()` should be entered for a CUDA/HIP
spelling regardless of the target. Note that this branching structure was
introduced by commit 3b9ebe92011b033523217a9b9a2f03f4c8c37aab.
Actually, why is `handleDeviceKernelAttr()` trying to call `handleGlobalAttr()`
at all? `handleDeviceKernelAttr()` is only called for `AT_DeviceKernel`.
`handleGlobalAttr()` handles `AT_CUDAGlobal` and `CUDAGlobalAttr` remains
separate from `DeviceKernelAttr`.
The more I look at the residual effects of the merge of device kernel
attributes, the more I think it was not a well motivated or positive change.
https://github.com/llvm/llvm-project/pull/163859
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
