[PATCH] D53705: [OpenCL] Postpone PSV address space diagnostic

[Ronan Keryell via Phabricator via cfe-commits]

keryell added a comment.

In https://reviews.llvm.org/D53705#1281743, @rjmccall wrote:

>




> New versions of C++ have semi-regularly added keywords like `static_assert` and `thread_local` that are not in the reserved space for identifiers.  When C adopted these, it spelled them `_Static_assert` and `_Thread_local`, which are in the reserved space.  I was under the mistaken (right?) impression thought that e.g. `__constant` was a standardized spelling, and I thought that Khronos had just decided to avoid using the unreserved identifiers in C++ when it had gladly adopted them in C.

Thank you for the clarification.

>   But now I understand that OpenCL C++ is attempting to be a radically different language model that does not actually have qualifiers at all.

Yes.

> By "0 language extension", do you just mean no *syntactic* extensions?  Because something like `cl::priv` certainly seems like it requires intrinsic language support, and I don't know what `add_global_t` could possibly do besides add a not-described-in-the-standard-but-still-obviously-there address-space qualifier so that member accesses continue to work and properly preserve the qualifier on the resulting l-value.  C++ doesn't provide adequate language tools to replace pointers and references at a language level, not by a long shot; the tools are only really good enough for resource management.

Since it is C++, you can do a lot with some wrapper classes and so not requiring visible language extensions.
But yes, if you dig into the implementation, it will use some attributes, address-spaces and so on.

> The "just compile C++ code for the GPU" idea that (IIRC) AMD has been exploring seems quite interesting, but unlike OpenCL C++ it really is a largely no-extensions approach: it's implementing the classic C++ language model (with facilities for taking more control) like any other frontend, just with a weird target on the backend.  It's also just hoping that the optimizer will be able to eliminate the overheads when mapping to a multiple-address-space model, and I'm not sure whether that's been borne out.  OpenCL C++ seems to be trying to strike a middle ground where there are minimal syntactic extensions but the type system is rather radically different in ways that often work but also often don't, and it's basically held together by the underlying extensions that it's pretending aren't there.  That doesn't seem like a successful language approach.

I was really meaning "run on the CPU" and not "run on the GPU", it was not a typo from me. :-)
If there are no visible language extensions besides C++ classes, it is easier to run the kernel code on a CPU without any specific compiler support, with just a plain C++ compiler and just by changing the runtime to launch the kernel.
It was part of the design motivation to remove the alien keywords.
This is even more true with SYCL.

>> That seems like a good discussion topic next Thursday at the LLVM Bay Area Meetup. :-)
> 
> Alas, I live in New York; I was just out there for the Developer's Meeting but won't be back for some time.

We will miss you, then. :-)


Repository:
  rC Clang

https://reviews.llvm.org/D53705