Skip to content

[SYCL][NFCI] Drop __spirv_ops.hpp from core.hpp #18839

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: sycl
Choose a base branch
from

Conversation

AlexeySachkov
Copy link
Contributor

Our device compiler have been capable of automagically declaring necessary SPIR-V built-ins on the fly for a while now, meaning that we don't need them to be forward-declared in headers.

This PR drops includes of __spirv_ops.hpp so that they don't appear anymore in core.hpp (and some other headers).

The header is not removed entirely, however, because not every built-in is known to the compiler, i.e. some of them still have to be forward-declared in the header.

Most likely there are other places which can be made free of uses of the header and the header itself can probably be cleaned up agressively, but I will leave it for separate future PRs.

Our device compiler have been capable of automagically declaring
necessary SPIR-V built-ins on the fly for a while now, meaning that we
don't need them to be forward-declared in headers.

This PR drops includes of `__spirv_ops.hpp` so that they don't appear
anymore in `core.hpp` (and some other headers).

The header is not removed entirely, however, because not every built-in
is known to the compiler, i.e. some of them still have to be
forward-declared in the header.

Most likely there are other places which can be made free of uses of the
header and the header itself can probably be cleaned up agressively, but
I will leave it for separate future PRs.
@@ -73,10 +73,10 @@ template <typename T, typename Properties>
void prefetch_impl(T *ptr, size_t bytes, Properties properties) {
#ifdef __SYCL_DEVICE_ONLY__
auto *ptrGlobalAS =
reinterpret_cast<__attribute__((opencl_global)) const char *>(
reinterpret_cast<__attribute__((opencl_global)) const unsigned char *>(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note for reviewers: compiler only declares signed and unsigned char overloads, hence the change.

We could probably tweak the compiler to have plain char overloads as well, but I'm not sure that it won't cause any unwanted side effects, so I went with this change for now.

unsigned char should be a safe choice when it comes to object representation

@AlexeySachkov AlexeySachkov marked this pull request as ready for review June 13, 2025 12:50
@AlexeySachkov AlexeySachkov requested review from a team as code owners June 13, 2025 12:50
Copy link
Contributor

@sarnex sarnex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

esimd lgtm

@sarnex sarnex requested a review from a team June 13, 2025 14:26
@uditagarwal97
Copy link
Contributor

Our device compiler have been capable of automagically declaring necessary SPIR-V built-ins on the fly for a while now, meaning that we don't need them to be forward-declared in headers.

Can you share more on how does that work?

// Atomic SPIR-V builtins
// TODO: drop these forward-declarations.
// As of right know, compiler does not forward-declare long long overloads for
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// As of right know, compiler does not forward-declare long long overloads for
// As of now, compiler does not forward-declare long long overloads for

@bader
Copy link
Contributor

bader commented Jun 13, 2025

Our device compiler have been capable of automagically declaring necessary SPIR-V built-ins on the fly for a while now, meaning that we don't need them to be forward-declared in headers.

Can you share more on how does that work?

@uditagarwal97, see patches from @Naghasan: #1345, #1374, #1384.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants