[NFCI][SYCL] Assert KernelHasName in StoreLambda
#19990
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I don't understand what not having a name was supposed to mean and it doesn't make any sense to me. The only failures I've seen after implementing this change is when we compile SYCL code with non-SYCL compiler without any SYCL knowledge (as in `clang++ -fsycl -fsycl-host-compiler=<...>` does have SYCL knowledge provided via integration headers). If anyone knows why this change would be incorrect, please let me know.
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
requested review from
AlexeySachkov,
sergey-semenov and
vinser52
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
sergey-semenov
approved these changes
Sep 8, 2025
| @@ -1,4 +1,4 @@ | |||
| // RUN: %clangxx %fsycl-host-only -fsyntax-only -Xclang -verify -Xclang -verify-ignore-unexpected=note,warning %s | |||
| // RUN: %clangxx -D__SYCL_UNITTESTS %fsycl-host-only -fsyntax-only -Xclang -verify -Xclang -verify-ignore-unexpected=note,warning %s | |||
There was a problem hiding this comment.
It's unexpected to see __SYCL_UNITTESTS here. Might be worth a comment, if not renaming of the macro.
There was a problem hiding this comment.
I'm open to other name suggestions.
There was a problem hiding this comment.
What about moving -D__SYCL_UNITTESTS into %fsycl-host-only substitution? That way it would be automatically applied to all tests and the name wouldn't matter much. And if we don't need to type it for every test, then __SYCL_UNITTESTS_BYPASS_KERNEL_NAME_CHECK would be pretty self-explanatory.
Because regardless of the name, any new test which aims to check something on host-only is doomed to fail because the macro isn't defined and it won't be obvious to a test author what is wrong.
There was a problem hiding this comment.
That's brilliant, let me do that.
|
@intel/llvm-gatekeepers please consider merging |
| @@ -1,4 +1,4 @@ | |||
| // RUN: %clangxx -%fsycl-host-only -c -ffp-accuracy=high -faltmathlib=SVMLAltMathLibrary -fno-math-errno %s | |||
| // RUN: %clangxx -fsycl -c -ffp-accuracy=high -faltmathlib=SVMLAltMathLibrary -fno-math-errno %s | |||
There was a problem hiding this comment.
This test is now slower, because it performs compilation twice, we should probably rewrite it to use SYCL_EXTERNAL functions to keep doing host-only compilation without the need for -D__SYCL_UNITTESTS.
Unrelated: not having -o %t.out is also an unsafe, because it could lead to race conditions with other tests written without -o %t.out as they could both attempt to write into a.o file at the same time
| @@ -1,4 +1,4 @@ | |||
| // RUN: %clangxx %fsycl-host-only -fsyntax-only -Xclang -verify -Xclang -verify-ignore-unexpected=note,warning %s | |||
| // RUN: %clangxx -D__SYCL_UNITTESTS %fsycl-host-only -fsyntax-only -Xclang -verify -Xclang -verify-ignore-unexpected=note,warning %s | |||
There was a problem hiding this comment.
What about moving -D__SYCL_UNITTESTS into %fsycl-host-only substitution? That way it would be automatically applied to all tests and the name wouldn't matter much. And if we don't need to type it for every test, then __SYCL_UNITTESTS_BYPASS_KERNEL_NAME_CHECK would be pretty self-explanatory.
Because regardless of the name, any new test which aims to check something on host-only is doomed to fail because the macro isn't defined and it won't be obvious to a test author what is wrong.
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
sergey-semenov
approved these changes
Sep 8, 2025
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
added a commit
to aelovikov-intel/llvm
that referenced
this pull request
Sep 11, 2025
Downstream CI uncovered another scenario where `detail::CompileTimeKernelInfo<KernelName>.Name` might be empty (other than non-SYCL compilation in some of the [unit]tests). That happens when compiling the same TU using multiple offload models (e.g., both SYCL and OMP) and the device compilation for non-SYCL model doesn't use SYCL integration header to provide kernel information. Ideally, we should be just guarding `static_assert`s with some `#if __SYCL_WHATEVER` but we don't set any SYCL-related macro when using 3rd party host compilers. Deal with that by turning compile-time `static_assert` into a run-time `assert` unless we can guarantee that SYCL kernel information is available.
aelovikov-intel
added a commit
to aelovikov-intel/llvm
that referenced
this pull request
Sep 11, 2025
Downstream CI uncovered another scenario where `detail::CompileTimeKernelInfo<KernelName>.Name` might be empty (other than non-SYCL compilation in some of the [unit]tests). That happens when compiling the same TU using multiple offload models (e.g., both SYCL and OMP) and the device compilation for non-SYCL model doesn't use SYCL integration header to provide kernel information. Ideally, we should be just guarding `static_assert`s with some `#if __SYCL_WHATEVER` but we don't set any SYCL-related macro when using 3rd party host compilers. Deal with that by turning compile-time `static_assert` into a run-time `assert` unless we can guarantee that SYCL kernel information is available.
aelovikov-intel
added a commit
to aelovikov-intel/llvm
that referenced
this pull request
Sep 11, 2025
Downstream CI uncovered another scenario where `detail::CompileTimeKernelInfo<KernelName>.Name` might be empty (other than non-SYCL compilation in some of the [unit]tests). That happens when compiling the same TU using multiple offload models (e.g., both SYCL and OMP) and the device compilation for non-SYCL model doesn't use SYCL integration header to provide kernel information. Ideally, we should be just guarding `static_assert`s with some `#if __SYCL_WHATEVER` but we don't set any SYCL-related macro when using 3rd party host compilers. Deal with that by turning compile-time `static_assert` into a run-time `assert` unless we can guarantee that SYCL kernel information is available.
aelovikov-intel
added a commit
to aelovikov-intel/llvm
that referenced
this pull request
Sep 11, 2025
Downstream CI uncovered another scenario where `detail::CompileTimeKernelInfo<KernelName>.Name` might be empty (other than non-SYCL compilation in some of the [unit]tests). That happens when compiling the same TU using multiple offload models (e.g., both SYCL and OMP) and the device compilation for non-SYCL model doesn't use SYCL integration header to provide kernel information. Ideally, we should be just guarding `static_assert`s with some `#if __SYCL_WHATEVER` but we don't set any SYCL-related macro when using 3rd party host compilers. Deal with that by turning compile-time `static_assert` into a run-time `assert` unless we can guarantee that SYCL kernel information is available.
aelovikov-intel
added a commit
to aelovikov-intel/llvm
that referenced
this pull request
Sep 11, 2025
Downstream CI uncovered another scenario where `detail::CompileTimeKernelInfo<KernelName>.Name` might be empty (other than non-SYCL compilation in some of the [unit]tests). That happens when compiling the same TU using multiple offload models (e.g., both SYCL and OMP) and the device compilation for non-SYCL model doesn't use SYCL integration header to provide kernel information. Ideally, we should be just guarding `static_assert`s with some `#if __SYCL_WHATEVER` but we don't set any SYCL-related macro when using 3rd party host compilers. Deal with that by turning compile-time `static_assert` into a run-time `assert` unless we can guarantee that SYCL kernel information is available.
aelovikov-intel
added a commit
to aelovikov-intel/llvm
that referenced
this pull request
Sep 11, 2025
Downstream CI uncovered another scenario where `detail::CompileTimeKernelInfo<KernelName>.Name` might be empty (other than non-SYCL compilation in some of the [unit]tests). That happens when compiling the same TU using multiple offload models (e.g., both SYCL and OMP) and the device compilation for non-SYCL model doesn't use SYCL integration header to provide kernel information. Also, my previous comments about `__usmfill` turned out to be incorrect. We do NOT unconditionally instantiate any of those in the `sycl/handler.hpp`, it was individual unittests that did that.
aelovikov-intel
added a commit
that referenced
this pull request
Sep 12, 2025
…0060) Follow-up for #19990 Downstream CI uncovered another scenario where `detail::CompileTimeKernelInfo<KernelName>.Name` might be empty (other than non-SYCL compilation in some of the [unit]tests). That happens when compiling the same TU using multiple offload models (e.g., both SYCL and OMP) and the device compilation for non-SYCL model doesn't use SYCL integration header to provide kernel information. Ideally, we should be just guarding `static_assert`s with some `#if __SYCL_WHATEVER` but we don't set any SYCL-related macro when using 3rd party host compilers. Deal with that by turning compile-time `static_assert` into a run-time `assert` unless we can guarantee that SYCL kernel information is available. --------- Co-authored-by: Sergey Semenov <sergey.semenov@intel.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I don't understand what not having a name was supposed to mean and it doesn't make any sense to me. The only failures I've seen after implementing this change is when we compile SYCL code with non-SYCL compiler without any SYCL knowledge (as in
clang++ -fsycl -fsycl-host-compiler=<...>does have SYCL knowledge provided via integration headers).If anyone knows why this change would be incorrect, please let me know.