-
Notifications
You must be signed in to change notification settings - Fork 407
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
Clean up AnalyzePolicy #3564
Clean up AnalyzePolicy #3564
Conversation
Retest this 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.
Otherwise, this looks good AFAICT.
template <class... Traits> | ||
struct AnalyzePolicy<void, Impl::IsGraphKernelTag, Traits...> | ||
: AnalyzePolicy<void, Traits...> { | ||
using is_graph_kernel = 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.
Are multiple GraphKernelTag
s allowed? Don't you need to make sure that none of the base class template parameters is Impl::IsGraphKernelTag
?
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.
Fine by me
typename PolicyBase::launch_bounds, | ||
typename PolicyBase::work_item_property, std::true_type>; | ||
//------------------------------------------------------------------------------ | ||
// Work item propoerty case |
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.
// Work item propoerty case | |
// Work item property case |
// A tag class for dependent defaults that must be handled by the | ||
// PolicyTraitsWithDefaults wrapper, since their defaults depend on other traits | ||
struct dependent_policy_trait_default; |
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.
Does not need a definition?
Apparently
so apparently |
Right now, the size of the code for AnalyzePolicy scales quadratically with the number of traits we analyze. With this change, the scaling is linear and adding a new trait doesn't have to touch any other code.
The details of the runtime storage that may be associated with a policy trait is now implemented only as part of the trait-specific specializations. Traits are now fully disjoint with the exception of defaults in AnalyzePolicy<void> and PolicyTraitsWithDefaults
6f572a5
to
200440f
Compare
|
More extensive disentangling of Policy Traits (Replaces #3564)
Right now, the size of the code for
AnalyzePolicy
scales quadraticly with the number of traits we analyze. With this change, the scaling is linear and adding a new trait doesn't have to touch any other code. There's nothing fancy going on here; we're just using partial specialization to detect the various traits. The one trick that was missing before is that we have to extract the work tag using an unspecialized template that defers to a base with a different name (which is partially specialized) before going back to the analysis of the rest of the traits.