question about vec_type_hint

[zjin-lcf]

For the warning: unknown attribute 'vec_type_hint' ignored [-Wunknown-attributes] when building a SYCL program, what is the equivalent attribute ?

Could you please also explain why it is deprecated ?

Thanks

[AlexeySachkov]

Hi @zjin-lcf, could you please share an example of how exactly your are using the attribute?

The thing is that spelling of attributes is different between SYCL 1.2.1 and SYCL 2020: the former allows to put them on functions using __attribute__((attr-name)) style, while the latter only allows [[sycl::]] applied to SYCL kernel functions.

By default our compiler uses SYCL 2020 mode (can be changed with -sycl-std= flag) and therefore ignores the old version of the spelling.

[zjin-lcf]

HI Aaron, when porting OpenCL programs, please advise which attribute or feature a user should choose after "vec_type_hint" is deprecated.

Thanks,

[AaronBallman]

I don't know what attribute it should be replaced with, if any. The SYCL 2020 spec doesn't suggest a replacement (https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#table.kernel.attributes), but perhaps someone else knows the answer to this. Tagging some folks who may know: @gmlueck and @MrSidims.

[rolandschulz]

This attribute has no effect on how we compile for our HW and therefore can be safely ignored when porting code. Looking at your code comment "manually vectorised kernel" it seems what you are trying to do is write explicitly vectorized kernels. If so what you want to use is reqd_sub_group_size(1) together with a way to write SIMD types. For the later we have https://github.com/intel/llvm/tree/sycl/sycl/doc/extensions/ExplicitSIMD. Please note that it's an extension under active development and the syntax will continue to evolve.

[zjin-lcf]

Does the attribute has any effect in an OpenCL kernel ?
If so, could you continue to support the attribute in SYCL without introducing Explicit SIMD ? Ideally, users don't need to know about Explicit SIMD ; the compiler is able to do the SIMD for a user implicitly or explicitly. SYCL supports vector operations with the "vec" class. Is the "vec" class not sufficient ? I understand that the low-level ESIMD is for performance. Could you incorporate ESIMD into the implementation of the "vec" class ? Thanks.

[AlexeySachkov]

Does the attribute has any effect in an OpenCL kernel ?

I guess it depends on the implementation. Tagging @cdai2 and @bashbaug here to comment.

SYCL supports vector operations with the "vec" class. Is the "vec" class not sufficient ?

There are discussions about vec class being too generic, i.e. that it is not clear whether it was intended from explicit SIMD programming or just to represent an equivalent for vectors from regular math.
This is one of the reasons for introducing marray into SYCL 2020:

A new math array type marray has been defined to begin disambiguation of the multiple possible interpretations of how sycl::vec should be interpreted and implemented.

I understand that the low-level ESIMD is for performance. Could you incorporate ESIMD into the implementation of the "vec" class ?

I guess that this will be done at some point, but likely for something different than vec. For example, we have an extension (unimplemented one), which incorporates std::simd into SYCL: InvokeSIMD. Tagging @Pennycook and @gmlueck here to comment on the language future/plans.