[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

Yaxun Liu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri May 6 11:46:12 PDT 2022


yaxunl marked an inline comment as done.
yaxunl added inline comments.


================
Comment at: clang/include/clang/Basic/Features.def:274
+// CUDA/HIP Features
+FEATURE(cuda_noinline_keyword, true)
+
----------------
aaron.ballman wrote:
> yaxunl wrote:
> > aaron.ballman wrote:
> > > Do the CUDA or HIP specs define `__noinline__` as a keyword specifically? If not, this isn't a `FEATURE`, it's an `EXTENSION` because it's specific to Clang, not the language standard.
> > CUDA/HIP do not have language spec. In their programming guide, they do not define `__noinline__` as a keyword.
> > 
> > Will make it an extension.
> > CUDA/HIP do not have language spec. 
> 
> Then what body of people governs changes to the language? Basically, I'm trying to understand whether this patch meets the community requirements for adding an extension: https://clang.llvm.org/get_involved.html#criteria, specifically #4 (though the rest of the points are worth keeping in mind). I don't want to Clang ending up stepping on toes by defining this extension only to accidentally frustrate the CUDA community.
specific to `__noinline__`, it is largely determined by the existing behaviour of CUDA SDK.

The CUDA SDK defines `__noinline__` as a macro `__attribute__((noinline))`. However, it is not compatible with some C++ headers which use `__attribute__((__noinline__))`.

This patch will not change the usage pattern of `__noinline__`. It is equivalent to the original behaviour with the benefit of being compatible with C++ headers.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124866/new/

https://reviews.llvm.org/D124866



More information about the cfe-commits mailing list