This is an archive of the discontinued LLVM Phabricator instance.

[libc] Add a support library for GPU utilities
ClosedPublic

Authored by jhuber6 on Apr 18 2023, 7:52 AM.

Details

Summary

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.

Diff Detail

Event Timeline

jhuber6 created this revision.Apr 18 2023, 7:52 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 18 2023, 7:52 AM
jhuber6 requested review of this revision.Apr 18 2023, 7:52 AM
jhuber6 updated this revision to Diff 514665.Apr 18 2023, 9:35 AM

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

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.

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).

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.

sivachandra accepted this revision.Apr 19 2023, 12:15 AM
sivachandra added inline comments.
libc/src/__support/GPU/CMakeLists.txt
11

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.

This revision is now accepted and ready to land.Apr 19 2023, 12:15 AM
jhuber6 added inline comments.Apr 19 2023, 5:11 AM
libc/src/__support/GPU/CMakeLists.txt
11

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.

This revision was automatically updated to reflect the committed changes.