Skip to content

Conversation

@PietroGhg
Copy link
Contributor

Adds support to specialization constants by scheduling the SpecConstantsPass in 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

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, thank you

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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 *

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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.

@PietroGhg
Copy link
Contributor Author

Hi @AlexeySachkov, do you have any more thoughts about this PR?

@omarahmed1111 omarahmed1111 force-pushed the pietro/native_cpu_specconstants branch from 29be54d to a77b395 Compare September 13, 2024 13:59
@omarahmed1111 omarahmed1111 force-pushed the pietro/native_cpu_specconstants branch from a77b395 to d01810c Compare September 13, 2024 14:00
@PietroGhg
Copy link
Contributor Author

Hi @intel/llvm-gatekeepers, this looks ready to merge, thank you

@martygrant martygrant merged commit f011892 into intel:sycl Sep 16, 2024
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.

6 participants