KhronosGroup / KhronosGroup/SYCL-Docs
Questions about type aliases
- Dominant language
- JavaScript
- Stars
- 158
- Forks
- 80
- Avg merge
- 7d 6h
- Merged PRs (30d)
- 5
Description
Hi folks,
I've been looking into [intel/llvm](https://github.com/intel/llvm) SYCL implementation details after `vector_aliases` SYCL-CTS [update](https://github.com/KhronosGroup/SYCL-CTS/commit/6a36e9b12752465b87a41dfd47487e26f5b47474) 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`. However, in SYCL 2020 we only have `sycl::opencl::cl_int`, but not `sycl::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](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_aliases) defines aliases `long{n}` and `ulong{n}`, which correspond to `sycl::vec` and `sycl::vec`. However, `long` data type in C++ is not guaranteed to be 64 bits.
To me, this looks a bit weird to have `sycl::vec` and `sycl::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 only `long 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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.