-
Notifications
You must be signed in to change notification settings - Fork 769
[WIP] Defer arg extraction until handler::finalize #18413
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
Conversation
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 much prefer this direction over #18387.
// Store information about the kernel arguments. | ||
void *MKernelFuncPtr = nullptr; | ||
int MKernelNumArgs = 0; | ||
detail::kernel_param_desc_t (*MKernelParamDescGetter)(int) = nullptr; | ||
bool MKernelIsESIMD = false; |
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 wonder if we can just keep that inside HostKernel
class.
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.
Probably? My original hope here was that we could get rid of HostKernel
, but I didn't appreciate that we need it in order to extend the lifetime of the kernel function until handler::finalize
is called.
I'm going to focus on getting a version of things that works and demonstrates the optimizations, but once I reach that point I'm open to talking about where the variables should go.
Rather than extracting arguments from the lambda when the kernel is enqueued, store a pointer to the lambda alongside relevant information from the integration header or compiler builtins. Storing this information will allow us to defer the extraction of arguments until we reach handler::finalize(), at which point it may be possible to set the kernel arguments directly without populating MArgs. Signed-off-by: John Pennycook <[email protected]>
a22ad96
to
172d504
Compare
I'm not planning to merge this yet, but for my own notes: the only tests failing here are the ones in #18416. |
I've folded this into #18387, so closing this now. |
A significant number of tests are failing in #18387, so I'm trying something simpler first. The aim of this PR is to defer the extraction of arguments from a lambda until
handler::finalize()
is called. If this works, then we can move to optimizing the extraction of arguments as a second step.