Skip to content

[SYCL] Correct spec about constness of get(properties_tag) member and add respective warning #17947

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

Merged
merged 2 commits into from
Apr 14, 2025

Conversation

HPS-1
Copy link
Contributor

@HPS-1 HPS-1 commented Apr 10, 2025

Currently some of our docs suggest using get(properties_tag) {...} member in kernel functors to specify kernel properties while some suggest using get(properties_tag) const {...}. But actually get(properties_tag) {...} might not work under certain conditions, so we should update the incorrect docs that they suggest readers to use get(properties_tag) const {...} rather than get(properties_tag) {...}.

Also as @Pennycook suggested, added a diagnostic warning to indicate the user when:
-they have declared a get(properties_tag) member in the kernel functor
AND
-they declared get(properties_tag){...} rather than get(properties_tag) const {...}

Updated the tests containing the non-const version of get(properties_tag) as well.

@HPS-1 HPS-1 temporarily deployed to WindowsCILock April 10, 2025 04:47 — with GitHub Actions Inactive
@HPS-1 HPS-1 temporarily deployed to WindowsCILock April 10, 2025 05:20 — with GitHub Actions Inactive
@HPS-1 HPS-1 temporarily deployed to WindowsCILock April 10, 2025 05:20 — with GitHub Actions Inactive
@HPS-1 HPS-1 marked this pull request as ready for review April 10, 2025 14:39
@HPS-1 HPS-1 requested review from a team as code owners April 10, 2025 14:39
@HPS-1 HPS-1 requested review from Bensuo and againull April 10, 2025 14:39
Copy link
Contributor

@kbenzie kbenzie left a comment

Choose a reason for hiding this comment

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

UR LGTM

Copy link
Contributor

@Bensuo Bensuo left a comment

Choose a reason for hiding this comment

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

Graph changes LGTM!

@HPS-1 HPS-1 temporarily deployed to WindowsCILock April 11, 2025 20:54 — with GitHub Actions Inactive
@HPS-1 HPS-1 temporarily deployed to WindowsCILock April 11, 2025 21:08 — with GitHub Actions Inactive
@HPS-1 HPS-1 temporarily deployed to WindowsCILock April 11, 2025 21:08 — with GitHub Actions Inactive
@HPS-1 HPS-1 temporarily deployed to WindowsCILock April 11, 2025 21:17 — with GitHub Actions Inactive
@HPS-1
Copy link
Contributor Author

HPS-1 commented Apr 14, 2025

Requesting @intel/llvm-gatekeepers to merge this. Thanks!

@sarnex sarnex merged commit 507679a into intel:sycl Apr 14, 2025
32 of 35 checks passed
@@ -338,7 +338,7 @@ struct KernelFunctor {
a[i] = b[i] + c[i];
}

auto get(sycl::ext::oneapi::experimental::properties_tag) {
auto get(sycl::ext::oneapi::experimental::properties_tag) const {
Copy link
Contributor

Choose a reason for hiding this comment

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

@Pennycook , I think there was some other PR where it was decided that kernel properties can't be runtime. Should we change this to static constexpr instead?

Copy link
Contributor

Choose a reason for hiding this comment

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

Adding @gmlueck and @rolandschulz per @Pennycook 's suggestion.

Also note that we need to modify

template <typename TransformedArgType, int Dims, typename KernelType>
class RoundedRangeKernel {
to propagate the properties, making this constexpr static would make that much easier.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that kernel properties will always be compile-time. For a case where a runtime property is required, I think we would use a launch property instead. Therefore, it seems like it's OK to make this static constexpr.

Copy link
Contributor

Choose a reason for hiding this comment

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

I found the discussion @aelovikov-intel was referencing over in #17633, where we ended up adding both static constexpr and auto versions to deal with compile-time and run-time properties.

Committing to only compile-time properties would solve the problem here and simplify that extension, so I'm also happy to make this static constexpr.

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.

9 participants