The GPU has many features that can only be accessed through builtin or
intrinsic functions. Furthermore, these functions are unique for each
GPU target. This patch outlines an interface to create a common libc
interface to access these. Currently I only implement a function for the
CUDA equivalent of blockIdx.x. More will be added in the future.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Adding a 'generic' folder. This will be a shim that tries to return something
reasonable when called from a non-GPU target. This will primarily be used for
RPC which needs to be compiled on the CPU and GPU. Also this makes my language
server happy because otherwise it doesn't define the function.
It seems like an abstraction over these things shows up in essentially every GPU codebase. I think they're a good candidate for clang intrinsics that translate to the corresponding platform specific incantation.
However there are currently no such intrinsics and it's hard to anticipate how well received such a proposal would be so I'm very much I'm favour of the approach you're taking here. Long term maybe the file would shrink to zero as intrinsics are created.
It seems credible that this could be a header only library. I know openmp devicertl does it's own thing based around variant dispatch but maybe it wouldn't be the worst thing to include header files from libc for part of that. It would use intrinsics if they existed I think.
So, one
Yeah, separation here is done via the macros. Intrinsics would be a solution here, but it's difficult to find a common set sometimes, since not every Nvidia builtin matches an AMD one. it would actually be possible to export these via the libc interface as an extension. But providing this as a library might be less optimal than handling it in LLVM.
I'm not too happy with the name but the concept seems like something we need (to duplicate or move) here.
Works for me if we cannot find a better name(ing scheme).
What would a better name be? I just went with utils since a lot of the other random libc stuff is XXXutil.
libc/src/__support/GPU/CMakeLists.txt | ||
---|---|---|
10 | Not a strong opinion but you can simplify few things here if you use files like nvptx_utils.h etc. instead of nested files nvptx/utils.h etc. | |
libc/src/__support/RPC/rpc.h | ||
23 | Is this new inclusion being used anywhere or is it only to make rpc.h expose utils.h implicitly? For proper layering, we normally avoid such implicit dependencies and inclusions. |
libc/src/__support/GPU/CMakeLists.txt | ||
---|---|---|
10 | I wanted to keep a single utils.h file that you can include and get the correct definition for that target. | |
libc/src/__support/RPC/rpc.h | ||
23 | A future patch will require it, so I just put it here to make sure that it worked, I can remove it for this patch if needed. |
Not a strong opinion but you can simplify few things here if you use files like nvptx_utils.h etc. instead of nested files nvptx/utils.h etc.