Skip to content

[SYCL] Add warning for attributes applied to non-kernel functions #15154

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 20 commits into from
Sep 17, 2024

Conversation

dyniols
Copy link
Contributor

@dyniols dyniols commented Aug 21, 2024

According to 5.8.1. Kernel attributes, kernel attributes can only be applied to SYCL kernel functions, but not to a regular device functions.

Based on this information, this pull request introduces a warning diagnostic whenever specified attributes are applied to regular device functions.

@dyniols dyniols marked this pull request as ready for review August 21, 2024 15:43
@dyniols dyniols requested a review from a team as a code owner August 21, 2024 15:43
@dyniols
Copy link
Contributor Author

dyniols commented Aug 26, 2024

@intel/dpcpp-cfe-reviewers Can you review?

@dyniols
Copy link
Contributor Author

dyniols commented Aug 28, 2024

@premanandrao I did requested changes can you look over them? Thanks

Copy link
Contributor

@elizabethandrews elizabethandrews left a comment

Choose a reason for hiding this comment

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

I am not sure if my suggestion of looking into deferred diagnostics was the right one here. What happens when you modify collectSYCLAttributes and emit the warning when DirectlyCalled >1

@dyniols
Copy link
Contributor Author

dyniols commented Sep 2, 2024

@elizabethandrews Do you know how to check if function is a kernel in CollectSyclExternalFuncs?

@dyniols
Copy link
Contributor Author

dyniols commented Sep 4, 2024

Okay, I investigated it, and it seems that dependency checks on attributes were unnecessary.

@dyniols
Copy link
Contributor Author

dyniols commented Sep 9, 2024

@elizabethandrews Could you look at my changes?

@@ -17,7 +17,8 @@

// Produce a conflicting attribute warning when the args are different.
[[sycl::work_group_size_hint(4, 1, 1)]] void f3(); // expected-note {{previous attribute is here}}
[[sycl::work_group_size_hint(1, 1, 32)]] void f3() {} // expected-warning {{attribute 'work_group_size_hint' is already applied with different arguments}}
Copy link
Contributor

Choose a reason for hiding this comment

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

The additional warnings in all these tests makes the tests a bit messy IMO. I would just remove (if we already test that functionality elsewhere) or rewrite the incorrect tests to not generate this warning. But this might just be me nit-picking. @premanandrao @smanna12 what do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think in this specific case, I need to remove
[[sycl::work_group_size_hint(1, 1, 32)]] void f3() {}
because it can only be a host or device function, but not a kernel. As a result, applying this attribute generates a warning.

Copy link
Contributor

@elizabethandrews elizabethandrews Sep 13, 2024

Choose a reason for hiding this comment

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

I understand. My point was that these test cases are no longer really relevant in this context. For example in this case, if we already have other tests testing work_group_size_hint incorrectly applied on the kernel, we don't need to be testing it on device/host functions since we are already warning they are incorrect as per your new warning anyway. It is not a big deal keeping these tests. It just makes the test cases a bit messy IMO.

I am ok submitting this PR as-is and cleaning up the tests in a separate PR if the other reviewers @premanandrao and @smanna12 want these tests cleaned up as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

I would like the tests cleaned up, but not necessarily as part of this PR. Are you okay with that @elizabethandrews?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would like the tests cleaned up, but not necessarily as part of this PR

I have same opinion. Agree with @elizabethandrews and @premanandrao

Copy link
Contributor

Choose a reason for hiding this comment

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

Are you okay with that @elizabethandrews?

Works for me. @DYNIO-INTEL please clean up the tests in a follow up PR

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It works for me too. I will clean up the tests in a follow up PR.

@@ -17,7 +17,8 @@

// Produce a conflicting attribute warning when the args are different.
[[sycl::work_group_size_hint(4, 1, 1)]] void f3(); // expected-note {{previous attribute is here}}
[[sycl::work_group_size_hint(1, 1, 32)]] void f3() {} // expected-warning {{attribute 'work_group_size_hint' is already applied with different arguments}}
Copy link
Contributor

@elizabethandrews elizabethandrews Sep 13, 2024

Choose a reason for hiding this comment

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

I understand. My point was that these test cases are no longer really relevant in this context. For example in this case, if we already have other tests testing work_group_size_hint incorrectly applied on the kernel, we don't need to be testing it on device/host functions since we are already warning they are incorrect as per your new warning anyway. It is not a big deal keeping these tests. It just makes the test cases a bit messy IMO.

I am ok submitting this PR as-is and cleaning up the tests in a separate PR if the other reviewers @premanandrao and @smanna12 want these tests cleaned up as well.

Copy link
Contributor

@smanna12 smanna12 left a comment

Choose a reason for hiding this comment

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

LGTM. Thank you

@steffenlarsen
Copy link
Contributor

@mdtoguchi - Driver/sycl.c on Windows has been failing in post-commit as of yesterday for unrelated changes (#15297) and this PR is the first case I've seen it fail in pre-commit. Do you have any idea of how to address it? Can we disable it temporarily?

@mdtoguchi
Copy link
Contributor

@mdtoguchi - Driver/sycl.c on Windows has been failing in post-commit as of yesterday for unrelated changes (#15297) and this PR is the first case I've seen it fail in pre-commit. Do you have any idea of how to address it? Can we disable it temporarily?

@steffenlarsen, it should be OK to disable temporarily (maybe just use REQUIRES: system-linux) until I can figure out what is going on.

@steffenlarsen
Copy link
Contributor

Failure in Driver/sycl.c for Windows is known and will be disabled in #15416.

@steffenlarsen steffenlarsen merged commit 227af47 into intel:sycl Sep 17, 2024
11 of 12 checks passed
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.

6 participants