-
Notifications
You must be signed in to change notification settings - Fork 794
[SYCL][NATIVECPU] Support specialization constants on Native CPU #14446
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][NATIVECPU] Support specialization constants on Native CPU #14446
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.
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.
Done, thank you
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 using default value is a reliable enough method, then I suggest to simply use it for all targets, simplifying this code.
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've changed this to always pass the default value type to generateSpecConstantMetadata, unfortunately we can't use the default type for everything because replaceAllUsesWith will fail since due to the ABI the type returned by the spec const builtin is different from the default 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.
Why is this cast needed? generateSpecConstantMetadata accepts 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.
You are right, the cast is removed now since we always use the default type, thank you
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.
Why is this test being marked as unsupported on native CPU if this PR is intended to add support for this feature? Does it mean that the test passed and this patch introduces a regression?
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.
We run Native CPU e2e tests downstream, we weren't running the tests in test-e2e/SpecConstants before this PR. With this PR all the tests in test-e2e/SpecConstants are passing, besides this one, which is also marked as UNSUPPORTED for other targets that use emulated SC, so this is not a regression.
|
Hi @AlexeySachkov, do you have any more thoughts about this PR? |
29be54d to
a77b395
Compare
a77b395 to
d01810c
Compare
|
Hi @intel/llvm-gatekeepers, this looks ready to merge, thank you |
Adds support to specialization constants by scheduling the
SpecConstantsPassin the Native CPU pass pipeline. A small change is needed in that pass since, due to ABI, the return type of the spec const builtins can't be used to determine the type of the spec constant, so for Native CPU we use the default value instead.UR PR: oneapi-src/unified-runtime#1821