ICE when using libcxx about llvm HOT 7 CLOSED

Although we can just rename the variable in libcxx, I wonder if we really need these __global, __local and __private aliases in SYCL. They should not be exposed to the users anyway, and for the SYCL library code we can use __attribute__((address_space(1))) syntax.

from llvm.

I think ComputeCpp does or used to do something similar to what you suggest (perhaps for other reasons): https://developer.codeplay.com/products/computecpp/ce/api-reference/base_8h

Maybe @Ruyk or @Naghasan will be able to elaborate on it or correct me though if my assumption is wrong

from llvm.

Another option is to use more OpenCL specific keywords (e.g. __opencl_global) instead of quite generic __global.
NOTE: address space are mapping is target dependent.

from llvm.

Although we can just rename the variable in libcxx, I wonder if we really need these __global, __local and __private aliases in SYCL. They should not be exposed to the users anyway

They need to be exposed somehow, as SYCL 1.2.1 defines interop type like global_ptr<T>::pointer, but it is up to the implementation to define the "how" as the definition is implementation defined.

I think the main problem here is that __global and co are keywords, which I believe is the root of the problem.

and for the SYCL library code we can use __attribute__((address_space(1))) syntax.

As @bader said, this sets a target address space, so its is actually different from the language address space.

I think ComputeCpp does or used to do something similar to what you suggest (perhaps for other reasons)

We expose the language address spaces as an attribute, which limits the exposure.

Another option is to use more OpenCL specific keywords (e.g. __opencl_global) instead of quite generic __global.

__global is defined by the OpenCL specs so you can't change it (e.g. https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf section 6.5.1). Although, does it need to a be a keyword ? Or can it be made context sensitive ?

Maybe @AnastasiaStulova has an opinion on this

from llvm.

__global is defined by the OpenCL specs so you can't change it (e.g. https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf section 6.5.1). Although, does it need to a be a keyword ? Or can it be made context sensitive ?

We are not required to expose OpenCL address spaces using keywords defined the OpenCL spec. The option I mentioned tries to expose OpenCL concept using different keyword, although it might not solve the fundamental problem.

from llvm.

I think this is related to my earlier question about your overall approach to address spaces (#59 (comment))

There are obviously a multiple options available and whichever you select will affect the rest of your compilation flow I believe.

In C++ for OpenCL upstream we are using language address spaces just like we used in OpenCL C. They are enabled by both "__" prefixed spelling and without. However, it is still work in progress and it heavily relies on generic address space feature that I believe is not available in SYCL 1.2...

If you are using __attribute__((address_space(...))) in C++ code it has a lot less support at the moment and it's also being changed currently https://reviews.llvm.org/D62574. But it is fundamentally different because it is attached to a target and not to the language itself. It is therefore not intended to be portable between targets. I feel it might not be the best fit for SYCL. You might want to review RFC thread on this topic mentioned in the review.

from llvm.

In triSYCL we use __attribute__((address_space(...))) for now.

from llvm.