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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
