-
Notifications
You must be signed in to change notification settings - Fork 795
[SYCL] Remove is_property_value
/is_property_value_of
#15899
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
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 |
---|---|---|
|
@@ -200,11 +200,10 @@ inline constexpr boo_key::value_t<Ts...> boo; | |
=== Property traits | ||
|
||
All runtime and compile-time-constant properties must have a specialization of | ||
`is_property_key` and `is_property_value` that inherits from | ||
`std::true_type`, and they must have a specialization of `is_property_key_of` | ||
and `is_property_value_of` | ||
that inherits from `std::true_type` for each SYCL runtime class that the | ||
property can be applied to. All have a base case which inherits from `std::false_type`. | ||
`is_property_key` that inherits from `std::true_type`, and they must have a | ||
specialization of `is_property_key_of` that inherits from `std::true_type` for | ||
each SYCL runtime class that the property can be applied to. All have a base | ||
case which inherits from `std::false_type`. | ||
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. Since we don't have separate traits for "key" and "value", should we rename these traits to 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 don't think it would be wise. The remaining traits (after this PR) still apply to the keys, while future |
||
|
||
```c++ | ||
namespace sycl::ext::oneapi::experimental { | ||
|
@@ -221,18 +220,6 @@ struct is_property_key_of<foo_key, SyclObjectT> : std::true_type {}; | |
template<typename SyclObjectT> | ||
struct is_property_key_of<bar_key, SyclObjectT> : std::true_type {}; | ||
|
||
// is_property_value and is_property_value_of based on is_property_key(_of) | ||
template<typename V, typename=void> struct is_property_value; | ||
template<typename V, typename O, typename=void> struct is_property_value_of; | ||
// Specialization for runtime properties | ||
template<typename V> struct is_property_value<V, std::enable_if_t<(sizeof(V)>0)>> : is_property_key<V> {}; | ||
template<typename V, typename O> struct is_property_value_of<V, O, std::enable_if_t<(sizeof(V)>0)>> : is_property_key_of<V,O> {}; | ||
// Specialization for compile-time-constant properties | ||
template<typename V> struct is_property_value<V, std::void_t<typename V::key_t>> : | ||
is_property_key<typename V::key_t> {}; | ||
template<typename V, typename O> struct is_property_value_of<V, O, std::void_t<typename V::key_t>> : | ||
is_property_key_of<typename V::key_t, O> {}; | ||
|
||
} // namespace experimental::oneapi::ext::sycl | ||
``` | ||
|
||
|
This file was deleted.
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 saw you made this comment in an old PR. I assume your concern is related to this new property work that you're doing, so let's discuss it here.
I would like to change
is_property_key_of
(is_property_of
) into a more general trait that works even for properties that are not used in a constructor. For example, some of the free functions related to the kernel compiler take properties, and I'd like to useis_property_of
to indicate which properties are allowed.My thought was to define a new class name something like this:
and then allow application code to test whether a property is allowed for this function via
is_property_of_v<Prop, build_source_bundle_properties>
.I think the same strategy could be used in #14743 to define a trait that can be used to tell which properties are allowed in a
launch_config
.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.
If
build_source_bundle_properties
is just a property list (type), do we need a trait at all? Could we just usebuild_source_bundle_properties.has_property<PropertyT>()
to check whether a given property exists in some list of valid properties?We could then extend this to classes by defining something like:
We wouldn't need to define
is_property_of
if we took this approach, but we could define it as a shorthand in terms of thisvalid_properties
member if we thought it was important.One consequence of this approach is that somebody wouldn't be able to add new properties to classes that aren't already expecting them. I don't know whether that's an advantage or a disadvantage.
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.
My proposed
build_source_bundle_properties
is not a property list. It's just an incomplete type, defined exactly as I show above in my comment. We just use this type as a sort of "handle" that can be used to identify a particular set of properties.The
valid_properties
approach you suggest only works for properties that are associated with some class (becausevalid_properties
is a class member). In the example I illustrate above with the kernel compiler, there is no relevant class. Instead, we want to know which properties are allowed to be used with a particular overload of thebuild
fiunction.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.
Sorry, I wasn't clear: I'm suggesting that instead of
build_source_bundle_properties
being an incomplete type, it could be defined as an alias to a property list type. We could still define multiple such aliases to cover multiple free functions. The difference in what I was proposing is that you'd be able to use members of the property list class to query what the list of valid properties contains, instead of having to create new traits.I only mentioned classes to show that defining a list of valid properties would also cover that case.
Uh oh!
There was an error while loading. Please reload this page.
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 it's better to have this discussion in #15752. What I'm trying to do is to use #15752 to determine our final goal and then have a bunch of trivial incremental changes that would eventually lead there. My current plan after this removal is to eliminate
template <...> class property_value
and (possibly in a separate PR) introduceproperty_base
. After that I'll move LLVM IR attribute metadata from a separate class directly to properties.As for this discussion, I tend to agree with @Pennycook. What I was envisioning before my last change there (eliminating property key type from the user interfaces) is
llvm/sycl/include/sycl/ext/oneapi/properties/new_properties.hpp
Lines 354 to 368 in 07ac818
then each interface (either class or free function) could just do SFINAE/
static_assert
overall_properties_in_v<PropListTy, foo_key, bar_key, baz_key>
. One can alias it if it's used in multiple places: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 like this, because property list is a collection of instances of properties (values) and not a collection of properties (types and/or templates). Also, having "conflicting" properties in a single property list feels hacky to me.
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.
Oh, I hadn't considered that. You're right, constructing an invalid property list just for the sake of describing the list of possible properties would be a bad idea.
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 suggest to continue this sub-thread in https://github.com/intel/llvm/pull/15752/files#r1821560396