[RFC] Add "cuda" clang-tidy module

Clang Frontend clang-tidy
1

I have in mind a check that should only be applicable in CUDA code (.cu files), not C++ code. I imagine there can be other checks that enforce best practices in CUDA-specific code.

  • Is it possible to enable such checks only on CUDA code, not in C++ code? I see there’s a LangOption called “CUDA” which seems it could be suitable.

  • Would it make sense to create a “cuda” clang-tidy module?

Thanks!

2
  • Is it possible to enable such checks only on CUDA code, not in C++ code? I see there’s a LangOption called “CUDA” which seems it could be suitable.

I just tested this and yes, using LangOpts.CUDA limits the check to analyzing .cu files, and ignores .cpp files.

1 Like
3

Sorry, it seems I had forgotten to write something.

IMO yes. It would of course be best to have more than one check inside a module. I don’t know how high the bar was for previous modules to be added, though.

One thing to point out, is that HIP should be supported by these checks as well. My understanding is, the difference is basically that HIP is a subset with a different prefix in the name. This opens up the question of the module name and if it should still be CUDA. (I have not used HIP)

4

Hello!

I just discovered that there’s officially some “CUDA C++ GUIDELINES for ROBUST and SAFETY CRITICAL PROGRAMMING”:

From here: 1. CUDA for Tegra — CUDA for Tegra 13.0 documentation

I think this gives more weight into making a cuda module for clang-tidy, where these rules could be implemented.

What do you think?

5

I’m generally supportive of new cuda module, hoping it will find its userbase.

However would like to have some prerequisites before landing new module.
Note that I’m speaking as someone who had very little experience with cuda.

  1. AFAIK nvidia use nvcc to compile cuda files, will clang frontend inside clang-tidy will be able to properly parse typical .cu files so it can run the analysis?
  2. Could we think of first N checks (at least 2-3) that we or someone else could implement. (and hopefully make an agreement to implement them in foreseeable future)
  3. Who would be major maintainer/reviewer with knowledge of cuda-dialect? I know little cuda myself so I personally don’t feel qualified enough to accept patches. Maybe folks from nvidia would like to take a look?
  4. We generally require the checks to run on large codebases to find false positives beforehand, do we have any such repos?

Also, not technical but “just wondering” questions:

  1. Are there any current active linters for cuda? We could compare clang-tidy to them and probably ask maintainers to take a look at clang-tidy implementation.
  2. Is there any interest from nvidia folks to have clang-tidy as linter, could we contact them and ask their opinion somehow? (Or maybe carlosgalvezp already nvidia employee :slight_smile:?)
6

Thanks for the input and great questions!

  1. Yes, we are using it successfully like that. One just needs to pass the correct flags as described here: Compiling CUDA with clang — LLVM 22.0.0git documentation . We do have already a test that covers an issue with a C++ check in CUDA, but it’s still a .cpp file. Would be good to test a pure .cu file as a test. Adaptations to the test framework may be needed.
  2. I think a fair amount are fairly trivial to implement, like 1.4, 1.8, 1.13. Others may be harder or even impossible if they require whole-program context. But I think it’s nevermind useful.
  3. Very good question! We’d need to find reviewers willing to do so of course. I have some experience but not too much bandwidth unfortunately.
  4. Good point. I think there’s a handful of repos out there, NVIDIA repos (cuda-samples, thrust), pytorch, tensorflow, etc. Don’t know how easy it is to integrate clang-tidy there though.
  5. I’m only aware of proprietary ones, like Axivion , Parasoft. Unsure they’d be willing to help increase the competition though :sweat_smile:
  6. Sure, I can raise it in the Nvidia forums. Unfortunately I’m not an employee :sweat_smile:

Now that I think about it, I guess one blocker similar to AUTOSAR is that the document has a Copyright notice by Nvidia, meaning we need to be careful about copying text from it. Maybe we’ll end up in the same situation :sad_but_relieved_face:

7

FYI @tstellar since you were involved in the AUTOSAR discussion.

8

There’s plenty of .cu tests under `clang/test/*.cu` so I think it should be no problem to follow that pattern for clang-tidy too.