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