Skip to content

[SYCL][NFCI] Rework spec constants metadata used for split - #15346

Merged
sarnex merged 1 commit into
intel:syclfrom
sarnex:splitspec
Sep 11, 2024
Merged

[SYCL][NFCI] Rework spec constants metadata used for split#15346
sarnex merged 1 commit into
intel:syclfrom
sarnex:splitspec

Conversation

@sarnex

@sarnex sarnex commented Sep 10, 2024

Copy link
Copy Markdown
Contributor

Addressing review feedback from #15271

Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
@sarnex
sarnex marked this pull request as ready for review September 10, 2024 17:45
@sarnex
sarnex requested a review from a team as a code owner September 10, 2024 17:45

@AlexeySachkov AlexeySachkov left a comment

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
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