-
Notifications
You must be signed in to change notification settings - Fork 770
[SYCL] Cache implicit local arg position info #18654
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
base: sycl
Are you sure you want to change the base?
Conversation
}; | ||
|
||
if (!KernelNameBasedCachePtr) | ||
return getLocalArgPos(); |
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.
As I understand, we keep this for backward compatibility? If so, we should keep it under the #ifndef __INTEL_PREVIEW_BREAKING_CHANGES
so that we can remove this code in the next window for the breaking changes.
std::optional<std::optional<int>> &ImplicitLocalArgPos = | ||
KernelNameBasedCachePtr->ImplicitLocalArgPos; | ||
if (!ImplicitLocalArgPos.has_value()) { | ||
ImplicitLocalArgPos = getLocalArgPos(); |
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 the kernel does not have an implicit arg, the m_KernelImplicitLocalArgPos
does not contain an entry for such kernel, and the getLocalArgPos
function returns an std::optional
that does not contain the value. So the if (!ImplicitLocalArgPos.has_value())
branch is always taken in that case. So I think we need to populate the KernelNameBasedCachePtr->ImplicitLocalArgPos
only once in the ProgramManager::addImage
function when we call the ProgramManager::cacheKernelImplicitLocalArg
.
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.
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.
Maybe we can initialize it when an instance of the KernelNameBasedCacheT
is created? What do you think?
No description provided.