-
Notifications
You must be signed in to change notification settings - Fork 787
[SYCL] Adds compile-time properties #4976
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] Adds compile-time properties #4976
Conversation
Implements the compile-time property list extension (https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/PropertyList/SYCL_EXT_ONEAPI_property_list.asciidoc) adding the sycl::ext::oneapi::property_list and sycl::ext::oneapi::property_value classes. These allow for compile-time inspection of properties passed to SYCL objects. These changes do not add support for the new property lists to any existing SYCL classes however. Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
@gmlueck | @rolandschulz | @Pennycook - It seems that MSVC is complaining because |
@steffenlarsen, can you try exactly the same syntax of |
Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
Thank you! That seems to have done the trick. |
Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
Runtime properties for the new property lists need to be seperately defined from the ones defined in SYCL 2020. These changes remove the support for SYCL 2020 properties in the compile-time property_list and adds the notion of runtime properties as a separate system. Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
Recent changes:
|
Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
I'm not going to dive in details but from high-level perspective the patch looks good for me. |
Of the LEWG members, @rolandschulz was most involved in the implementation details of compile-time properties. I was not planning to review in detail, but @rolandschulz might want to. |
@rolandschulz, could you take a look, please? |
@rolandschulz, ping. |
@rolandschulz - Could you please clarify if you plan on reviewing this? If not, @Pennycook would you mind having a look? |
Like Greg, I wasn't planning to do an in-depth review here. I did take a look when the PR was opened, but the template wizardry being employed is sufficiently advanced that I wouldn't feel comfortable reviewing for things like impact on compile-time, etc. FWIW, what I understood looks good, and I appreciated the "How to add a new property" comments -- I think those will be very useful. 👍 |
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.
Lime Gin Tastes Metallic!
// `sycl::ext::oneapi::experimental::detail::PropKind` representing the new | ||
// property. Increment | ||
// `sycl::ext::oneapi::experimental::detail::PropKind::PropKindSize` | ||
// 2. Define property key class with `value_t` that must be `property_value` |
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.
can these new property keys be in other namespaces?
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. There is no requirement on the namespace of the properties. It would probably be preferable to have them in a namespace under sycl::ext::oneapi::experimental
while it is still experimental, but since it is user-facing it should not be a requirement from the implementation.
namespace detail { | ||
template <> struct PropertyToKind<bar_key> { | ||
static constexpr PropKind Kind = | ||
static_cast<enum PropKind>(PropKind::PropKindSize + 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'm guessing the awkward PropKindSize + X
constructs here is because we aren't actually making modifications to property.hpp
, correct?
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.
Exactly. These properties are not "real" so we make their PropKind
outside the usual range to avoid confusing them with actual properties.
// (4.) | ||
template <> struct is_property<bar_key> : std::true_type {}; | ||
// Replace SYCL_OBJ with the SYCL object to support the property. | ||
template <> struct is_property_of<bar_key, SYCL_OBJ> : std::true_type {}; |
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.
what if the SYCL_OBJ class itself requires template specialization? Use a template template? Proxy? Will we have order-of-evaluation issues?
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.
is_property_of
is already a thing in SYCL 2020. For example, if we specialize for buffer we have something long the lines of
template <typename T, int Dimensions, typename AllocatorT>
struct is_property_key_of<bar_key, buffer<T, Dimensions, AllocatorT, void>> : std::true_type {};
I don't believe there should be any issues with that.
Signed-off-by: Steffen Larsen <[email protected]>
4608676
Signed-off-by: Steffen Larsen <[email protected]>
Signed-off-by: Steffen Larsen <[email protected]>
Failures were unrelated. They have been reported and testing has been restarted. |
@romanovvlad & @psamolysov-intel & @cperkinsintel - There has been some minor corrections to the how-to. Would you mind having another look? |
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 didn't review deeply, but what I see in the latest 3 commits looks good for me. Thanks, @steffenlarsen!
@intel/llvm-gatekeepers - Remaining questions have been answered. This should be ready for merge. |
@steffenlarsen, post-commit failed with
Could you fix these issues, please? |
#5684 should fix it. |
Implements the compile-time property list extension adding the
sycl::ext::oneapi::properties
andsycl::ext::oneapi::property_value
classes. These allow for compile-time inspection of properties passed to SYCL objects. These changes do not add support for the new property lists to any existing SYCL classes however.