[SYCL] Add support for structs containing special types as free function kernel parameters #18692
Conversation
lbushi25
changed the title
lbushi25
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
lbushi25
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
|
@intel/dpcpp-cfe-reviewers friendly ping for review |
There was a problem hiding this comment.
I'm concerned that a lot of additional info is gathered and stored which doesn't happen in SYCL2020 mode. I think we lack some additional modifications to visitors mechanism for free function kernels and we should extend that instead of storing additional data which is not stored for SYCL 2020 kernels.
I'm also fairly concerned with how much additional C++ code will be added to the integration header. C++ code generation and the whole integration header is proven to be heavily bug-prone. I'm not really sure generating the whole set_arg function is worth the complication and the maintenance burden. I think for SYCL RT it should be enough to know which parameter of generated spir_kernel function corresponds to which top-level parameter of the original free function kernel signature.
cc @tahonermann , @AlexeySachkov and @intel/llvm-reviewers-runtime for opinions. I'm also slightly concerned that the PR doesn't have passing E2E tests added for the case.
clang/include/clang/Sema/SemaSYCL.h
Outdated
| // A map that keeps track of all structs encountered with | ||
| // special types inside. Relevant for free function kernels only. | ||
| // The key stores the struct as a declaration and the value stores the struct | ||
| // as a QualType just to make it easier to use it. |
There was a problem hiding this comment.
I don't think it is that hard to obtain a type from a RecordDecl so we need to store it separately. Note there can be lots of kernels and lots of struct parameters within the same translation unit.
clang/lib/Sema/SemaSYCL.cpp
Outdated
| // TODO manipulate struct depth once special types are supported for free | ||
| // function kernels. | ||
| // ++StructFieldDepth; | ||
| ++StructFieldDepth; |
There was a problem hiding this comment.
Are these used for free function kernels now?
There was a problem hiding this comment.
They are not. Will remove them.
| @@ -4368,16 +4348,18 @@ class SyclKernelBodyCreator : public SyclKernelFieldHandler { | |||
| class FreeFunctionKernelBodyCreator : public SyclKernelFieldHandler { | |||
| SyclKernelDeclCreator &DeclCreator; | |||
| llvm::SmallVector<Stmt *, 16> BodyStmts; | |||
| // Keep track of the structs we have encountered on our way to a special type. | |||
| // They will be needed to properly generate the __init call. Note that the | |||
There was a problem hiding this comment.
How are these kept for SYCL 2020 kernels? How free function kernels are different from SYCL 2020 so we need this additional tracking?
There was a problem hiding this comment.
SyclKernelBodyCreator uses the MemberExprBases vector which serves a similar purpose. I think there is slightly less code this way for example MemberExprBases requires a bit more work to maintain properly as we enter and leave structs. Also FreeFunctionKernelBodyCreator does not inherit from SyclKernelBodyCreator so we are not wasting information. I just chose a slightly different way of doing things.
| FwdDeclEmitter.Visit( | ||
| member->getType().getDesugaredType(S.getASTContext())); | ||
| offsets.emplace_back(std::make_pair( | ||
| member, S.getASTContext().getFieldOffset(member) / 8)); |
There was a problem hiding this comment.
For SYCL 2020 kernels we calculate offsets in SyclKernelIntHeaderCreator. Why can't we do that for free function kernels.
| [[__sycl_detail__::add_ir_attributes_function("sycl-single-task-kernel", 0)]] | ||
| void ff_25(AccessorAndLocalAccessor arg1) { | ||
| } | ||
|
|
||
| [[__sycl_detail__::add_ir_attributes_function("sycl-single-task-kernel", 0)]] | ||
| void ff_26(AccessorAndLocalAccessor arg1, SecondLevelAccessor arg2) { | ||
| } | ||
|
|
||
| [[__sycl_detail__::add_ir_attributes_function("sycl-single-task-kernel", 0)]] | ||
| void ff_27(IntAndAccessor arg1, AccessorAndInt) { | ||
| } |
There was a problem hiding this comment.
I think we need more testing here. We need template structs, typedefed structs, namespaces, default template parameters and combinations of these.
Concerning the last statement, there is an E2E test added previously and I just removed the XFAIL's in this PR. |
…ushi25/llvm into struct_contains_special_types
lbushi25
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
Add support for structs containing special types as free function kernel parameters.