-
Notifications
You must be signed in to change notification settings - Fork 761
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
[WIP][SYCL] Implement sycl_special_class attribute #2091
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1135,6 +1135,20 @@ def SYCLKernel : InheritableAttr { | |
let Documentation = [SYCLKernelDocs]; | ||
} | ||
|
||
def SYCLSpecialClass: InheritableAttr { | ||
let Spellings = [Clang<"sycl_special_class">]; | ||
let Subjects = SubjectList<[CXXRecord]>; | ||
let LangOpts = [SYCLIsDevice, SYCLIsHost]; | ||
// TODO: Add doc | ||
let Documentation = [Undocumented]; | ||
let Args = [ | ||
EnumArgument<"SpecialClassKind", "SpecialClassKind", | ||
[ "accessor", "sampler", "stream", "" ], | ||
[ "Accessor", "Sampler", "Stream", "Generic" ], 1> | ||
Comment on lines
+1145
to
+1147
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have mainly looked at the attribute definition here. This seems to me to be very specific to SYCL and does not cover every special types (like specialization constant). Also if you want to add a new one, you need to change the compiler. One of the idea I had was to make the attribute sensitive to One drawback I see from a "generic attribute" point of view, this is C++ specific as
I disagree, OpenCL doesn't need to apply any kind of processing to build the entry point. SPIR-V is neutral to that regard as well. This is to allow regularization to an underlying programming model. So OpenCL or CUDA at the moment, but we could very well imagine something OpenMP or Vulkan compatible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, it doesn't cover specialization constant, I marked it as unfinished TODO in the PR description. In case of new special type... If the new special type needs some special handling that differs from others, you need to change the compiler anyway, otherwise "generic" value of the attribute can be used.
Could you please describe how it would look like? I'm not sure that I got the idea.
With the current implementation the runtime takes the address of kernel object and uses offsets encoded by the integration header. It also uses information about kernel object field types to cast area of memory accessed by using of address and offset to proper type and perform handling, it cannot query the type from raw memory. In this case we probably could teach integration header to emit information that some kernel argument is a 'special class' and add some base class for each class that is handled specially by the compiler, so this base class will hold kind of special class and it will be possible to query it, I guess. But I'm not really sure since I don't have a lot of experience with runtime. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This attribute doesn't do much. Special types processing boils down to fully or partially breakdown the structure into valid fields for your programming model. The rest is the associated processing in the runtime.
I'll take the
This is spread out in different places, but that's the basic idea. The important thing to notice is if you replace So in a more generic way, you could have
So for example: class __attribute__((sycl_special_class)) MySpecialType {
int Field1;
int Field2;
void __init(int F1) {
Field1 = F1;
Field2 = F1;
}
void __finalize() {}
public:
MySpecialType() = default;
int getF2() const { return Field2; }
}; If used in a kernel argument
This would trigger the following kernel entry point in the AST: void __sycl_kernel(int F1) {
MySpecialType T;
T.__init(F1);
// finish rebuilding the lambda + call
T.__finalize()
}
So the integration header already emits what kind of fields it is processing. Changing to this would only require the capability to query it in the runtime. Since the std-layout requirement was lifted, a simple base class and reinterpret cast should do the job. Another approach is to make the attribute take an ID as argument (the ID is chosen by the runtime) and forward it in the integration header (so in place of the field currently emitted). The runtime then only have to read-it directly. Either way, the compiler remains agnostic to the field it is processing. Hopes this make the idea clearer. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it definitely makes the idea clearer. Thanks for so detailed explanation! |
||
]; | ||
let PragmaAttributeSupport = 0; | ||
} | ||
|
||
// Marks functions which must not be vectorized via horizontal SIMT widening, | ||
// e.g. because the function is already vectorized. Used to mark SYCL | ||
// explicit SIMD kernels and functions. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -59,3 +59,9 @@ | |
#else | ||
#define __SYCL_INLINE_CONSTEXPR static constexpr | ||
#endif | ||
|
||
#if __has_attribute(sycl_special_class) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Minor. Suggest adding check: #ifdef SYCL_DEVICE_ONLY |
||
#define __SYCL_SPECIAL_CLASS(kind) __attribute__((sycl_special_class(kind))) | ||
#else | ||
#define __SYCL_SPECIAL_CLASS(kind) | ||
#endif |
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.
FYI: @erichkeane recently added
SYCLRequiresDecomposition
attribute, which probably can be re-used instead ofSYCLSpecialClass
.15e62c2
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.
SYCLRequiresDecomposition
attribute appears on user-defined struct kernel arguments if they should be passed to the kernel field-by-field, then these structs are constructed back on kernel side withoutinit
method usage. Classes which we want to identify withSYCLSpecialClass
(accessor, sampler, stream) are handled specially withinit
method. So, technically right nowSYCLRequiresDecomposition
attribute works in a bit other use case. To re-use this attribute we will need to change some logic.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.
presumably SYCLSpecialClass is a subset of the SYCLRequiresDecomposition. I think we still would need BOTH, as the Special-class needs to understand how to deal with the 'init' function, but it should also be translated to the requires-decomp.