[SYCL] Implement device_has kernel property and macro

[steffenlarsen]

This commit implements the device_has kernel property and the SYCL_EXT_ONEAPI_FUNCTION_PROPERTY macro from the
sycl_ext_oneapi_kernel_properties extension.

Known current limitations:

• The LLVM IR attributes from add_ir_attributes_function are not correctly generated on SYCL_EXTERNAL functions.
• The SYCL_EXT_ONEAPI_FUNCTION_PROPERTY cannot currently be placed after SYCL_EXTERNAL.

[steffenlarsen]

The SYCL_EXT_ONEAPI_FUNCTION_PROPERTY cannot currently be placed after SYCL_EXTERNAL.

This is currently a restriction in Clang's parsing of attributes, which to my knowledge is being loosened in upstream. @gmlueck & @Pennycook - Would it make sense to accept the limitation for now and add a note about it in the extension instead of finding a work-around?

[Pennycook]

@gmlueck & @Pennycook - Would it make sense to accept the limitation for now and add a note about it in the extension instead of finding a work-around?

I think so; this would unblock developers who are waiting on function properties, and we could get more implementation experience.

Also, Clang's handling of attributes and SYCL_EXTERNAL must already be problematic for us (because SYCL 2020 says that SYCL_EXTERNAL can have attributes on either side), so we're already expecting developers to workaround ordering restrictions for our compiler.

[gmlueck]

The SYCL_EXT_ONEAPI_FUNCTION_PROPERTY cannot currently be placed after SYCL_EXTERNAL.

This is currently a restriction in Clang's parsing of attributes, which to my knowledge is being loosened in upstream. @gmlueck & @Pennycook - Would it make sense to accept the limitation for now and add a note about it in the extension instead of finding a work-around?

OK with me too, but we should add a NOTE in the Status section about the restriction.

Just curious ... SYCL_EXTERNAL also expands to a C++ attribute. What is the restriction in Clang that prevents arbitrary ordering? Since they're both attributes, it seems surprising that Clang cares about their order.

[steffenlarsen]

Just curious ... SYCL_EXTERNAL also expands to a C++ attribute. What is the restriction in Clang that prevents arbitrary ordering? Since they're both attributes, it seems surprising that Clang cares about their order.

It is only a problem because one uses the __attribute__(...) interface and the other uses the [[...]] one. @elizabethandrews made a nice godbolt example to show this. From local testing, changing SYCL_EXTERNAL to use [[...]] doesn't help because it may already be ordered after other existing __attribute__ cases.

[cperkinsintel]

LGTM

[elizabethandrews]

Just curious ... SYCL_EXTERNAL also expands to a C++ attribute. What is the restriction in Clang that prevents arbitrary ordering? Since they're both attributes, it seems surprising that Clang cares about their order.

It is only a problem because one uses the __attribute__(...) interface and the other uses the [[...]] one. @elizabethandrews made a nice godbolt example to show this. From local testing, changing SYCL_EXTERNAL to use [[...]] doesn't help because it may already be ordered after other existing __attribute__ cases.

Do we know why SYCL_EXTERNAL was implemented using GNU spelling (__attribute__ syntax) and not CXX spelling? I see we've also implemented sycl_global_var with GNU spelling. Do we expect to use these attributes in headers? If so, MSVC won't be able to compile headers since it does not support GNU spellings for attributes. Should we change these attributes (and other SYCL attributes if any) to use C++ spelling. I assume it will break tests and maybe user code which uses SYCL_EXTERNAL after GNU attributes.

[steffenlarsen]

Should we change these attributes (and other SYCL attributes if any) to use C++ spelling. I assume it will break tests and maybe user code which uses SYCL_EXTERNAL after GNU attributes.

I am for changing it, but I think it would be safer to defer it to after attribute lists are made order-agnostic. As soon as that happens I don't see why us changing it would cause user-code breaks as they do not use it directly but rather through the SYCL_EXTERNAL macro, unless of course they use new/old headers with an old/new compiler.