[clang] Fallback to C calling convention for sycl_kernel attribute #161349

camc · 2025-09-30T10:27:05Z

Fixes a crash. Let the device kernel calling convention be C when not compiling OpenCL. sycl_kernel in this context then has no effect, as expected.

llvmbot · 2025-09-30T10:27:36Z

@llvm/pr-subscribers-clang-codegen

@llvm/pr-subscribers-clang

Author: None (camc)

Changes

Resolves #161077

Fixes a crash. Let the device kernel calling convention be C when not compiling OpenCL. sycl_kernel in this context then has no effect, as expected.

Full diff: https://github.com/llvm/llvm-project/pull/161349.diff

3 Files Affected:

(modified) clang/docs/ReleaseNotes.rst (+1)
(modified) clang/lib/CodeGen/TargetInfo.cpp (+2-1)
(added) clang/test/CodeGen/sycl-kernel.c (+5)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index e8deae50e4cb0..74580b77353d5 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -397,6 +397,7 @@ Bug Fixes to Attribute Support
 - Using ``[[gnu::cleanup(some_func)]]`` where some_func is annotated with
   ``[[gnu::error("some error")]]`` now correctly triggers an error. (#GH146520)
 - Fix a crash when the function name is empty in the `swift_name` attribute. (#GH157075)
+- Fix a crash when the ``sycl_kernel`` attribute is used while not compiling OpenCL (#GH161077).
 
 Bug Fixes to C++ Support
 ^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/clang/lib/CodeGen/TargetInfo.cpp b/clang/lib/CodeGen/TargetInfo.cpp
index 1e58c3f217812..4ff847f4f6ff6 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -123,8 +123,9 @@ unsigned TargetCodeGenInfo::getDeviceKernelCallingConv() const {
     // conventions; different targets might split structs passed as values
     // to multiple function arguments etc.
     return llvm::CallingConv::SPIR_KERNEL;
+  } else {
+    return llvm::CallingConv::C;
   }
-  llvm_unreachable("Unknown kernel calling convention");
 }
 
 void TargetCodeGenInfo::setOCLKernelStubCallingConvention(
diff --git a/clang/test/CodeGen/sycl-kernel.c b/clang/test/CodeGen/sycl-kernel.c
new file mode 100644
index 0000000000000..77410e5a216ff
--- /dev/null
+++ b/clang/test/CodeGen/sycl-kernel.c
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -emit-llvm %s -o /dev/null
+
+__attribute__((sycl_kernel)) void foo(int *ret) {
+  *ret = 1;
+}

github-actions · 2025-09-30T10:28:42Z

⚠️ We detected that you are using a GitHub private e-mail address to contribute to the repo.
Please turn off Keep my email addresses private setting in your account.
See LLVM Developer Policy and LLVM Discourse for more information.

Fznamznon · 2025-09-30T11:31:13Z

clang/lib/CodeGen/TargetInfo.cpp

+  } else {
+    return llvm::CallingConv::C;


I'm not sure this is entirely right solution.
IMO we should probably ignore sycl_kernel attribute if the target is not offloading target, similar to amggpu_kernel attribute. However it maybe not worth doing if sycl_kernel attribute is going to be removed in favor of clang::sycl_kernel_entry_point attribute which BTW has the same crashing problem. cc @tahonermann

I agree with Mariya on this one. we're going to run into a ton of problems if we are trying to use offloading attributes when not offloading. We should just ignore the attribute and throw the appropriate warning.

Makes sense, I didn't see it was ignored correctly for amdgpu. It seems this is because isMultiSubjectAttrAllowedOnType returns false for non-amdgpu, so it is skipped and then not ignored and diagnosed in getCCForDeclaratorChunk. Not sure the purpose of this isMultiSubjectAttrAllowedOnType check, is it still necessary @sarnex? Doesn't seem ideal to have to split amdgpu/non-amdgpu cases.

Right, the annoying problem is that the AMDGPU attribute is allowed both on types and functions, and all the others are allowed only on functions, so I had to allow the AMDGPU type case but bail on all others. As far as I know this logic is still required, but I don't think we can unify the logic unless we unify the allowed subjects for the attributes.

Ah yeah that's annoying, I'll special case AMDGPU for now.

Let me try removing it and see what explodes, will post my results here

I got it down to one test failure, hopefully should have something tomorrow

The handling here seems absolutely inconsistent. Why is amdgpu_kernel considered a sycl kernel. Why doesn't device_kerel imply a kernel for AMDGPU but does for NVPTX? See https://godbolt.org/z/61f7bY3n6, you should be able to apply function attributes before the function declaration as far as I know.

Yeah that's crazy. I guess I unified the attribute names but didn't completely unify the semantics. I don't know that we can do that for sure, but I'll try. To be honest I expect to hit a ton of nonsense.

Actually there was only minimal nonsense, should have a PR shortly.

We have multiple different attributes in clang representing device kernels for specific targets/languages. Refactor them into one attribute with different spellings to make it more easily scalable for new languages/targets. --------- Signed-off-by: Sarnie, Nick <[email protected]>

…targets (#161905) The original [change](#137882) unifying the device kernel attributes had some inexplicable behavior, such as `amdgpu_kernel` resulting in a function ending up with the `spir_kernel` CC but `nvptx_kernel` not doing the same, both cases compiling for SPIR. There was also a [crash](#161077). `sycl_kernel` is now separated out from `device_kernel`, but still there was some weird behavior for the remaining spellings. For the target-specific spellings (`nvptx_kernel` and `amdgpu_kernel`), while not technically required, we warn and ignore the attribute if the spelling doesn't match the target because it's weird from the user's point of view to allow it. Also we make sure that any valid usage actually applies the CC to the generated `llvm:Function`. This worked for `NVPTX` already but was missing for `SPIR/SPIR-V` and `AMDGPU`, it needs to be explicitly done in `TargetInfo`. This allows us to remove the `amdgpu_kernel` specific handing we had. That special handling was previously required because it was the only variation that was allowed on a type, and thus had a separate way to propagate the CC. These issues were reported [here](#161077) and [here](#161349). Closes: #161077 --------- Signed-off-by: Sarnie, Nick <[email protected]>

… different targets (#161905) The original [change](llvm/llvm-project#137882) unifying the device kernel attributes had some inexplicable behavior, such as `amdgpu_kernel` resulting in a function ending up with the `spir_kernel` CC but `nvptx_kernel` not doing the same, both cases compiling for SPIR. There was also a [crash](llvm/llvm-project#161077). `sycl_kernel` is now separated out from `device_kernel`, but still there was some weird behavior for the remaining spellings. For the target-specific spellings (`nvptx_kernel` and `amdgpu_kernel`), while not technically required, we warn and ignore the attribute if the spelling doesn't match the target because it's weird from the user's point of view to allow it. Also we make sure that any valid usage actually applies the CC to the generated `llvm:Function`. This worked for `NVPTX` already but was missing for `SPIR/SPIR-V` and `AMDGPU`, it needs to be explicitly done in `TargetInfo`. This allows us to remove the `amdgpu_kernel` specific handing we had. That special handling was previously required because it was the only variation that was allowed on a type, and thus had a separate way to propagate the CC. These issues were reported [here](llvm/llvm-project#161077) and [here](llvm/llvm-project#161349). Closes: llvm/llvm-project#161077 --------- Signed-off-by: Sarnie, Nick <[email protected]>

…targets (llvm#161905) The original [change](llvm#137882) unifying the device kernel attributes had some inexplicable behavior, such as `amdgpu_kernel` resulting in a function ending up with the `spir_kernel` CC but `nvptx_kernel` not doing the same, both cases compiling for SPIR. There was also a [crash](llvm#161077). `sycl_kernel` is now separated out from `device_kernel`, but still there was some weird behavior for the remaining spellings. For the target-specific spellings (`nvptx_kernel` and `amdgpu_kernel`), while not technically required, we warn and ignore the attribute if the spelling doesn't match the target because it's weird from the user's point of view to allow it. Also we make sure that any valid usage actually applies the CC to the generated `llvm:Function`. This worked for `NVPTX` already but was missing for `SPIR/SPIR-V` and `AMDGPU`, it needs to be explicitly done in `TargetInfo`. This allows us to remove the `amdgpu_kernel` specific handing we had. That special handling was previously required because it was the only variation that was allowed on a type, and thus had a separate way to propagate the CC. These issues were reported [here](llvm#161077) and [here](llvm#161349). Closes: llvm#161077 --------- Signed-off-by: Sarnie, Nick <[email protected]>

llvmbot added clang Clang issues not falling into any other category clang:codegen IR generation bugs: mangling, exceptions, etc. labels Sep 30, 2025

camc force-pushed the sycl-kernel-crash branch from bfa6759 to acaf932 Compare September 30, 2025 10:39

Fznamznon requested review from sarnex and tahonermann September 30, 2025 11:28

Fznamznon reviewed Sep 30, 2025

View reviewed changes

llvmbot added the clang:frontend Language frontend issues, e.g. anything involving "Sema" label Sep 30, 2025

camc closed this Sep 30, 2025

camc force-pushed the sycl-kernel-crash branch from 31efdd2 to 1ad31d9 Compare September 30, 2025 23:42

camc mentioned this pull request Oct 2, 2025

[clang] Fix device_kernel attribute crash on unsupported targets when not using AMDGPU spelling #161687

Closed

sarnex mentioned this pull request Oct 3, 2025

[clang] Fix inconsistencies with the device_kernel attr on different targets #161905

Merged

[clang] Fallback to C calling convention for sycl_kernel attribute #161349

[clang] Fallback to C calling convention for sycl_kernel attribute #161349

Uh oh!

Conversation

camc commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Sep 30, 2025

Uh oh!

Fznamznon Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sarnex Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

camc Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

sarnex Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

camc Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

sarnex Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

sarnex Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

jhuber6 Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sarnex Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sarnex Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

camc commented Sep 30, 2025 •

edited

Loading

llvmbot commented Sep 30, 2025 •

edited

Loading

Fznamznon Sep 30, 2025 •

edited

Loading

sarnex Sep 30, 2025 •

edited

Loading

sarnex Oct 1, 2025 •

edited

Loading

jhuber6 Oct 2, 2025 •

edited

Loading

sarnex Oct 3, 2025 •

edited

Loading