tra added a comment. > This adds a cuda header type with file extension "cuh". The output type file > extension is "cuhi" - not sure if this is a good choice. This allows > language servers to properly handle cuh files without additional arguments.
CUDA compilation is ... odd. While I don't have strong objections to this change, I'm also not convinced that it's particularly useful, either. The problem is that just telling compiler that the header is a CUDA source is not sufficient. Clang relies on a lot of CUDA SDK headers in order to make the standard CUDA things like `__host__`, '__device__', `threadIdx`, etc work. For the CUDA source files clang pre-includes a lot of headers. I'm not quite sure what clang would be supposed to do when it's given a `.cuh` as an input. If we pre-include the CUDA headers as we do for `.cu` compilation, we'll get way more of the preprocessed output than the user would likely expect. If we do not pre-include CUDA headers, we'll not get CUDA macros expanded and the output would not be suitable to pass on to the further compilation. On one hand it does not make things worse. On the other, it does not make them better, either. If anything, Clang not recognizing CUDA headers on their own is probably better than accepting them and producing invalid output. Perhaps I'm missing something. Do you have specific use case in mind for this change? Also, AFAICT, there's no such thing as a canonical CUDA header file extension. Some projects use `.cuh`, some use `.cu.h`, some use just `.h` and other C++ extensions, so this change would only help with a subset of the headers. Then there's the fact that for CUDA compilation clang needs the headers from CUDA SDK. You can't just take a CUDA header and preprocess it with the default flags. If you want the preprocessed file content to match what would be seen in a real compilation when the header is included from the CUDA source file, you must ensure that the header was preprocesses with exactly the same CUDA SDK as the source file it would be included from. In general, `--cuda-path` should probably be treated as a required argument. I do not see a practical way to make `properly handle cuh files without additional arguments` work reliably. For that we'd need Clang to carry all required CUDA headers and that's not going to happen any time soon. That said, it may be worth considering implementing a `stand-alone` CUDA compilation mode which would provide the bare minimum of CUDA headers without having to include CUDA SDK headers. **That** would be useful for various tooling scenarios where we may need to deal with CUDA sources/headers but where we do not have CUDA SDK available and/or do not have access to correct `--cuda-path`. That would probably need to be implemented first. Once it's in place, preprocessing a CUDA header may make more sense as we'll be able to produce preprocessed output that would be closer to what would be expected from a preprocessor -- something compileable without too much extra stuff. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D94337/new/ https://reviews.llvm.org/D94337 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
