Skip to content
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][NFCI] Rework spec constants metadata used for split #15346

Merged
merged 1 commit into from
Sep 11, 2024

Conversation

sarnex
Copy link
Contributor

@sarnex sarnex commented Sep 10, 2024

Addressing review feedback from #15271

Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
Copy link
Contributor

@AlexeySachkov AlexeySachkov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good to me!

// extract spec constant maps per each module
SpecIDMapTy TmpSpecIDMap;
SpecConstantsPass::collectSpecConstantMetadata(M, TmpSpecIDMap);
if (!TmpSpecIDMap.empty()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that both spec constants metadata and default values metadata are in sync, i.e. if one is empty then another is also empty. However, I wonder if we need to note that in a comment, or in form of some assert in else branch put under #ifndef NDEBUG?

I'm just looking for what others think, I do not have a strong opinion here, so not asking to do any changes just yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems reasonable to me, let me add it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running unit tests, it seems it actually is the case that TmpSpecIDMap is empty but IsSpecConstantDefault is true, and I'm not sure if there are any other cases that should bet rue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merging for now, let me know if you have any other ideas on something we can assert, happy to implement it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running unit tests, it seems it actually is the case that TmpSpecIDMap is empty but IsSpecConstantDefault is true, and I'm not sure if there are any other cases that should bet rue.

What I meant is that collectSpecConstantMetadata and collectSpecConstantMetadata should either both return empty map, or should both return non-empty map. That's the implicit expectation we currently have.

I'm not sure what IsSpecConstantDefault is, but if that's a marker that device image contains default values of spec constants then it is also a weird state. That image should not be produced if there are no spec constants, because it will be no different from the original device image it was produced from. We even have an early exit in the corresponding function

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry the two functions you mentioned are the same, did you mean collectSpecConstantMetadata and collectSpecConstantDefaultValuesMetadata?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, copy-paste mistake

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that seems to work, pr coming soon. thanks

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sarnex sarnex merged commit 1b05b81 into intel:sycl Sep 11, 2024
14 checks passed
sarnex added a commit that referenced this pull request Sep 18, 2024
Follow up from #15346.

Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants