Open AlexeySachkov opened 1 year ago
To me, this looks a bit weird to have
sycl::vec<long, 2>
andsycl::long2
which are potentially different types.
I definitely agree that this is a problem, and I think this should be fixed in the SYCL 2020 spec. The problem exists also for the marray
aliases, and it exists for other alias variants like sycl::short
.
there is no alias for
long long
type
This seems like an oversight to me.
Hi folks,
I've been looking into intel/llvm SYCL implementation details after
vector_aliases
SYCL-CTS update and whilst looking into the SYCL spec I got a few questions about whether we want to add a few more type aliases into it or about how of the existing aliases are defined.No more aliases for OpenCL vector types?
In SYCL 1.2.1 we have aliases like
cl_int2 -> cl::sycl::vec<cl::sycl::cl_int, 2>
. However, in SYCL 2020 we only havesycl::opencl::cl_int
, but notsycl::opencl::cl_int2
. I was wondering: is there a particular reason for not including them?Potentially confusing alias
long{n}
4.14.2.2. Aliases defines aliases
long{n}
andulong{n}
, which correspond tosycl::vec<int64_t, n>
andsycl::vec<uint64_t, n>
. However,long
data type in C++ is not guaranteed to be 64 bits.To me, this looks a bit weird to have
sycl::vec<long, 2>
andsycl::long2
which are potentially different types. Someone who is not familiar with exact details of vector aliases may think that they are the same, but that may not always be true. I suppose that the idea could be to better match OpenCL, but isn't it better to align with C++ instead and add OpenCL-related aliases specific to the corresponding backend?Missing
longlong{n}
alias?Also, there is no alias for
long long
type. For someone, who comes from C++ background, where onlylong long
is guaranteed to be at least 64 bits, I think it maybe useful to have such an alias. Note that we had such an alias in SYCL 1.2.1 spec, but it didn't make it to SYCL 2020 by some reason.