-
Notifications
You must be signed in to change notification settings - Fork 745
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
[SYCL] Decompose kernel parameters and add inheritance support #1877
Conversation
Signed-off-by: rdeodhar <rajiv.deodhar@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
Vector types started appearing as top level arguments since they are wrapped with cl::sycl::vec class. Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
…They are decomposed and individual fields are passed Signed-off-by: Elizabeth Andrews <elizabeth.andrews@intel.com>
Signed-off-by: Elizabeth Andrews <elizabeth.andrews@intel.com>
through it's fields and initialize accessors using respective handlers. Other fields of stream class are not handled.
I think all lit tests except for those containing arrays should now pass. I think there are 3 with arrays in them. |
There is an issue with multiple streams in one command group. Debugging that now. |
Signed-off-by: Elizabeth Andrews <elizabeth.andrews@intel.com>
When I need to allow inherited
Are you sure, you do need changing those? |
This approach won't work for user-defined classes which have accessor as base class. We need to handle this generic case as well.
We don't changing those. |
I think to be sure here, we need to understand what is the purpose of your case. If your inherited accessor has its own implementation of |
clang/lib/Sema/SemaSYCL.cpp
Outdated
// FIXME: Can this be refactored/handled some other way? | ||
template <typename ParentTy, typename... Handlers> | ||
static void VisitStreamRecord(CXXRecordDecl *Owner, ParentTy &Parent, | ||
CXXRecordDecl *Wrapper, Handlers &... handlers) { | ||
(void)std::initializer_list<int>{(handlers.enterStruct(Owner, Parent), 0)...}; | ||
VisitAccessorWrapperHelper(Wrapper, Wrapper->bases(), handlers...); | ||
VisitAccessorWrapperHelper(Wrapper, Wrapper->fields(), handlers...); | ||
for (const auto &Field : Wrapper->fields()) { | ||
QualType FieldTy = Field->getType(); | ||
// Required to initialize accessors inside streams. | ||
if (Util::isSyclAccessorType(FieldTy)) | ||
KF_FOR_EACH(handleSyclAccessorType, Field, FieldTy); | ||
} | ||
(void)std::initializer_list<int>{(handlers.leaveStruct(Owner, Parent), 0)...}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the best way for us is to re-implement stream
class in SYCL headers, so it will look like accessor and we don't need to visit it's field in the compiler.
@againull , do you think it is possible?
Our use case is having some_accessor, which is inherited from accessor. Will this use case be covered by your patch? My own approach was: writing __init, changing |
Our intention was to implement support for user-defined inherited accessors. So passing some class which have accessor in base should work and |
Signed-off-by: Elizabeth Andrews <elizabeth.andrews@intel.com>
Signed-off-by: Elizabeth Andrews <elizabeth.andrews@intel.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NO comments on this for me, the stuff I understand all looks right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the changes look good to me.
…upport_2 Signed-off-by: Elizabeth Andrews <elizabeth.andrews@intel.com>
Signed-off-by: Elizabeth Andrews <elizabeth.andrews@intel.com>
a7ad39c
Merged latest changes from intel:sycl, fixing conflict (Just a variable name change). |
@intel/llvm-reviewers-runtime there are some runtime tests, could someone review them, please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The runtime tests look good to me, except for a single comment there.
Also, I believe it's an extension and not by-specification. Hence, a link to the extension proposal/spec would be a nice to have.
This is not an extension. SYCL specification technically doesn't prohibit inheritance for kernel arguments, kernel function objects and accessors, so this patch only adds handling of these missed cases. |
OK, then. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of improvement suggestions, which can be applied in separate PRs.
// CHECK-NEXT: { kernel_param_kind_t::kind_std_layout, 4, 12 }, | ||
// CHECK-NEXT: { kernel_param_kind_t::kind_std_layout, 4, 16 }, | ||
// CHECK-NEXT: { kernel_param_kind_t::kind_std_layout, 4, 20 }, | ||
// CHECK-NEXT: { kernel_param_kind_t::kind_std_layout, 4, 24 }, | ||
// CHECK-NEXT: { kernel_param_kind_t::kind_std_layout, 4, 28 }, | ||
// CHECK-NEXT: { kernel_param_kind_t::kind_std_layout, 4, 32 }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to decompose a struct consisting of standard trivially-copiable C++ types (i.e. which doesn't encapsulate a non-USM pointer or non-standard C++ type e.g. image or sampler).
Sending it like this will impact performance:
- we set 6 parameters instead of one, which means runtime overhead on calling "setArg" 6 times + potentially use more registers than needed to pass six 4-byte values instead of one 24-byte value
- it might complicate JIT compiler analysis (or may not).
I'm okay if we address this in follow-up commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we were planning to add this optimization after implementing basic functionality. I've created an issue to keep track on that #2043. @elizabethandrews , would you mind taking this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure will do.
Util::DeclContextDesc{clang::Decl::Kind::Namespace, "cl"}, | ||
Util::DeclContextDesc{clang::Decl::Kind::Namespace, "sycl"}, | ||
Util::DeclContextDesc{clang::Decl::Kind::Namespace, "detail"}, | ||
Util::DeclContextDesc{clang::Decl::Kind::Namespace, "half_impl"}, | ||
Util::DeclContextDesc{Decl::Kind::CXXRecord, Name}}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, add an attribute to annotate SYCL types like accessor, sampler, image. It's much more reliable approach than declaration name, which introduces hard-coded dependency on exact symbol name in the runtime library.
I suppose we need only one attribute to detect special types which must be handled as separate kernel parameters. If not, we can parameterize the attribute.
This refactoring can be done in a separate PR.
Tagging @Naghasan, who was going to contribute similar attribute from ComputeCPP implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, add an attribute to annotate SYCL types like accessor, sampler, image. It's much more reliable approach than declaration name, which introduces hard-coded dependency on exact symbol name in the runtime library.
I suppose we need only one attribute to detect special types which must be handled as separate kernel parameters. If not, we can parameterize the attribute.This refactoring can be done in a separate PR.
Tagging @Naghasan, who was going to contribute similar attribute from ComputeCPP implementation.
Right now just one attribute is not enough since we have differences between handling of different classes, especially in integration header support. It seems runtime library needs to handle each type in a different way, I have no idea how to redo it so it will be unified across different SYCL types.
Right now we can start with parameterized attribute, i.e. for example:
class accessor {
...
__attribute__((sycl_special_type(accessor))) DataT *Data;
}
...
class sampler {
...
__attribute__((sycl_special_type(sampler))) ocl_sampler_t Sampler;
}
Also, we can discuss it in upcoming upstreaming meeting.
I've created an issue to keep track on that #2041.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to point out that clang is able to differentiate sampler from accessor w/o any attributes - they are different types (pointer type vs __ocl_sampler_t).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, makes sense.
This type instruction describes a string, mostly for Fortran 90. Spec: KhronosGroup/SPIRV-Registry#186 Original commit: KhronosGroup/SPIRV-LLVM-Translator@beecd9d
This PR redesigns 'parameter passing' support for kernel parameters of struct type. All struct type SYCL kernel arguments (except special SYCL types) are now decomposed and their individual fields are passed as separate OpenCL kernel arguments.
Following issues are fixed after this PR:
This PR was a collaborative effort, with patches from Mariya Podchishchaeva and Elizabeth Andrews. For early testing, PR was updated periodically with changes from PR#1841 (Array support by Rajiv Deodhar). Changes from PR#1841 is not present in final diff since array support is now in intel:sycl.