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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D124866#3497439 <https://reviews.llvm.org/D124866#3497439>, @tra wrote:

>> CUDA/HIP do not have language spec.
>
> Well. It's not completely true. CUDA programming guide does serve as the de-facto spec for CUDA. It's far from perfect, but it does mention `__noinline__` and `__forceinline__` as function qualifiers: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#noinline-and-forceinline

Thank you, that's the magic words I was hoping for -- because they're described as function qualifiers, I think it's justifiable to add them as a keyword implementation in Clang and not worry about stepping on the toes of the CUDA spec (it's adhering to what the current spec requires).

Should we do `__forceinline__` at the same time so that there's consistency?



================
Comment at: clang/lib/Parse/ParseDecl.cpp:902
+  while (Tok.is(tok::kw___noinline__)) {
+    IdentifierInfo *AttrName = Tok.getIdentifierInfo();
+    SourceLocation AttrNameLoc = ConsumeToken();
----------------
yaxunl wrote:
> aaron.ballman wrote:
> > I think we should we be issuing a pedantic "this is a clang extension" warning here, WDYT?
> will do
I'm questioning whether my advice here was good or not -- now that I see the CUDA spec already calls these function qualifiers... it's debatable whether this is a Clang extension or just the way in which Clang implements the CUDA function qualifiers. @tra -- do you have opinions?

I'm sort of leaning towards dropping the extension warning, but the only reason I can think of for keeping it is if Clang is the only CUDA compiler that doesn't require you to include a header before using the function qualifiers. If that's the case, there is a portability concern.


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

https://reviews.llvm.org/D124866