Generic type name descriptions: massive problem

[Melirius]

I've got into a blocking issue on CTS because of this.

In the Table 165 there is an explosive mixture of types following vector and marray aliases. For example, charn gentype includes char{n}, mchar{n}, marray<{N},char> that (excluding misprint in marray defeinition) effectively covers char in marray, but int8_t in char{n} and mchar{n}. Then all the signatures that include e.g. sgeninteger are inherently contradictory as sgeninteger does not contain int8_t to match char{n}. Another aspect of the problem arises for e.g. genlong where it is possible to have sycl::long2 = sycl::vec<int64_t, 2> plus long = int32_t (this is totally standard C++ behavior, for example in MSVC) and this generic type mixes 32 and 64-bit types.

The solution to the part of the problem was suggested in this PR, but it is only palliative.

There are two ways out:

1. Simple: use full definitions like vec<char, {n}> in the table instead of char{n} for genchar. This, however, leads to a potential leak in function definitions: then functions are not required to support e.g. short2 as it is possible that on the C++ system int16_t is not in the list of fundamental types at all (for example 8-bit char and 32-bit short and int are fully compatible with the standard, and fixed types are not required to be aliases to any of fundamental types). This can be avoided by careful extension of the type tree of table 165 and a requirement that all fixed-size types should be supported for host and device in Sec. 5.5.
2. Hard: change aliases system. AFAIK it follows from OpenCL and is aligned with cl_ types, but in the current state that tries to align with C++ types it provides a lot of ways to shoot yourself in the foot.

[AlexeySachkov]

If I understand correctly, that table does not intend to reference aliases at all, i.e. if we take n = 2, then char{n} is a vec<char, 2> and not char2.

This is described in 4.17.1. Description of the built-in types available for SYCL host and device:

The generic type names themselves are not valid SYCL types, but they represent a set of valid types, as defined in Table 165. Each generic type within a section is comprised of a combination of scalar, SYCL vec and/or marray class specializations. The letters {n} and {N} define valid sizes for class specializations, where {n} means 2,3,4,8,16 and {N} means any positive value of size_t type. Note that any reference to the base type refers to the type of a scalar or the element type of a SYCL vec or marray specialization.

[Melirius]

That is correct, but 1) the table explicitly contains float2 etc. 2) then it appears that aliases and vectors/marrays of fixed-width types are not required to be supported in functions at all. I don't think that it was intended behavior, at least CTS contained tests for all the aliases (and even some surplus ones).

[Melirius]

So not to impede the CTS extension, I took for the tests that in the table and function definitions type{n} = vec<type, {n}>, mtype{n} = marray<type, {n}> and all general integer types are extended also by fixed-width types, like sigeninteger = signed char, short, int, long int, long long int, int8_t, int16_t, int32_t, int64_t.

[gmlueck]

Hard: change aliases system. AFAIK it follows from OpenCL and is aligned with cl_ types, but in the current state that tries to align with C++ types it provides a lot of ways to shoot yourself in the foot.

I think we should do this. The aliases defined in 4.14.2.2 and 4.14.3.2 are very confusing, and now it appears that even the spec authors got confused! There is already a proposal in #335 to fix the aliases, and I think we should do this in SYCL 2020 before anyone has adopted it.

[fraggamuffin]

aliases are not fixed-width types and we should only test fundamental types or just remove them instead of adding ones with different names
4.14.2.2 and 4.14.3.2 for vec and marray
deprecate these apis in sycl 2020m then remove in next release
for the test: dont remove if they are already there
what about generics? they can be bigger size as C++ only say the minimum, but let's create a separate issue for now

[fraggamuffin]

drafting phase