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

[CIR][HIP|CUDA] Generate global storing CUDA|HIP stub function #1341

Merged
merged 1 commit into from
Feb 19, 2025

Conversation

koparasy
Copy link
Contributor

@koparasy koparasy commented Feb 13, 2025

On HIP when launching a kernel we pass as a first argument a global variable that points to the device stub function.

We follow OG design by having a map that pairs globals to symbols. In CUDA this is effectively a nop, as CUDA passes the device stub as a first argument.

@koparasy koparasy changed the title Generates CUDA|HIP stub redirection [CIR][HIP|CUDA] Generate global storing CUDA|HIP stub function Feb 13, 2025
@koparasy koparasy force-pushed the features/hip-stub-runtime branch 2 times, most recently from ae7074f to 432d4f8 Compare February 13, 2025 23:28
@koparasy koparasy marked this pull request as ready for review February 14, 2025 00:06
@AdUhTkJm
Copy link
Contributor

This PR suggests we should use the function names, rather than the FuncOp itself, as the key to kernelHandles. That is because the same function might be created twice, once with incomplete types and once with complete types.

@koparasy
Copy link
Contributor Author

This PR suggests we should use the function names, rather than the FuncOp itself, as the key to kernelHandles. That is because the same function might be created twice, once with incomplete types and once with complete types.

Ok, I will add this.

@koparasy koparasy force-pushed the features/hip-stub-runtime branch from 432d4f8 to 98de2c5 Compare February 14, 2025 17:21
@koparasy koparasy force-pushed the features/hip-stub-runtime branch from 98de2c5 to 1b14d85 Compare February 14, 2025 17:43
@koparasy
Copy link
Contributor Author

This PR suggests we should use the function names, rather than the FuncOp itself, as the key to kernelHandles. That is because the same function might be created twice, once with incomplete types and once with complete types.

Ok, I will add this.

Done

Copy link
Member

@bcardosolopes bcardosolopes left a comment

Choose a reason for hiding this comment

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

Nit but otherwise ready to go

@bcardosolopes bcardosolopes merged commit ab985cc into llvm:main Feb 19, 2025
6 checks passed
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.

3 participants