Naghasan added a comment. In D80932#2072064 <https://reviews.llvm.org/D80932#2072064>, @Anastasia wrote:
> In D80932#2071321 <https://reviews.llvm.org/D80932#2071321>, @bader wrote: > > > In D80932#2068863 <https://reviews.llvm.org/D80932#2068863>, @Anastasia > > wrote: > > > > > > > > > > > > > > > > Why? Can you explain what you are trying to achieve with this? > > > > I think @asavonic can provide more detailed answer, but IIRC we spent a lot > > time trying to marry template meta-programming with OpenCL address space > > deductions, but even simplest template functions from C++ standard library > > breaks compilation. It's important to note one important difference in > > design goals for SYCL and C++ for OpenCL. SYCL aims to enable compilation > > of regular C++ as much as possible where as one of the C++ for OpenCL goals > > is to keep compatibility with OpenCL C. These two goals might lead to > > different design decisions. > > > I don't see a contradiction in those goals. We plan to support C++ libraries > with C++ for OpenCL of course with functionality that is accepted by > conformant OpenCL implementations. For example, libraries that use virtual > functions leading to function pointers are not going to work portably in > OpenCL devices. If SYCL aims to compile to conformant OpenCL devices then it > should not be very different I imagine? There is a fundamental difference (given the direction taken for OpenCL), OpenCL mode actively modifies user's types (C and C++ for OpenCL AFAIK). So inside a function, this: int var; becomes VarDecl var '__private int' Which is fine in C where you can't really do much with your types, but this has a massive and destructive effect in C++. For instance this does not compile in C++ for OpenCL: void foo() { int var; // '__private int' not 'int' int* ptr1 = &var; // '__generic int* __private' not 'int*' decltype(var)* ptr2 = ptr1; // error: cannot initialize a variable of type 'decltype(var) *__private' (aka '__private int *__private') with an lvalue of type '__generic int *__private' } > We plan to support C++ libraries with C++ for OpenCL With the direction taken so far, C++ for OpenCL can't properly implement or use basic C++ due to this. Trivial example using a `is_same` implementation (https://godbolt.org/z/CLFV6z): template<typename T1, typename T2> struct is_same { static constexpr int value = 0; }; template<typename T> struct is_same<T, T> { static constexpr int value = 1; }; void foo(int p) { static_assert(is_same<decltype(p), int>::value, "int is not an int?"); // Fails: p is '__private int' != 'int' static_assert(is_same<decltype(&p), int*>::value, "int* is not an int*?"); // Fails: p is '__private int*' != '__generic int*' } So yes, you could implement `std::is_same` but it won't work as one would expect. That's the reason why SYCL actively tries to prevent changing any type, this would prevent the compilation of valid C++ code without a fundamental reason (e.g. the target is not able to support it). > Default address space is a Clang concept that is generally used for an > automatic storage. That's not true in CUDA. On the other hand they actively avoids using address space. Plus in `isAddressSpaceSupersetOf` you have: // Consider pointer size address spaces to be equivalent to default. ((isPtrSizeAddressSpace(A) || A == LangAS::Default) && (isPtrSizeAddressSpace(B) || B == LangAS::Default)) An alternative would be to clone the address space. But that would be shame to not find a way to reuse the opencl one as down the line, they map to the same thing. ================ Comment at: clang/include/clang/AST/Type.h:493 + other.getAddressSpace()) || + (!hasAddressSpace() && + (other.getAddressSpace() == LangAS::opencl_private || ---------------- Not sure how to make it better, but this may not be true depending on what is allowed by the language. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80932/new/ https://reviews.llvm.org/D80932 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
