Fix kernel argument definition for named function objects#996
Fix kernel argument definition for named function objects#996ssam18 wants to merge 3 commits intoKhronosGroup:mainfrom
Conversation
The old text said only member variables referenced by operator() become kernel parameters, which is wrong when SYCL_EXTERNAL calls cross TU boundaries. All member variables are now stated as kernel arguments, with implementations allowed to drop unused ones via dead argument elimination.
|
|
|
I have signed the Contribution License Agreement, Still CI/CD workflow is pending on that. When I click, it shows you already have signed. Not sure how to fix it. |
|
@gmlueck said "I volunteered to draft a PR for this." Why are you not consulting with him before writing a PR? It's kind of rude... We are all human with feeling. |
No worries. Glad for the help! |
My intension is to not hurt your feeling. I am here to help and expedite the work for this group. You can collaborate here in this PR and take the credit, I don't mind. |
|
|
Maybe add a note to said that user can always by pass by specialization the trait to true? (to behave like cuda, jsut opt-out of the diagnostic) |
gmlueck
left a comment
gmlueck
left a comment
There was a problem hiding this comment.
Please fix reflow failure.
Done. |
5 participants
Fixes #915.
The previous wording implied that only member variables referenced by
operator()become kernel parameters, which breaks down whenoperator()calls aSYCL_EXTERNALfunction defined in another translation unit — the compiler has no way to know which members are used there. The corrected text states that all member variables of the named function object are kernel parameters, and that an implementation may drop any it can prove are unused (dead argument elimination). This also aligns with how DPC++ already handles type checking for kernel objects.