[SYCL] Add lightweight free-function kernel property headers

[koparasy]

Introduce lightweight kernel-property headers for free-function kernel annotation and launch-tuning use cases:

• function_properties.hpp provides a standalone path for execution-kind annotations such as nd_range_kernel and single_task_kernel.
• function_launch_properties.hpp provides a lightweight path for launch properties such as work_group_size, work_group_size_hint, and sub_group_size.
• kernel_properties/properties.hpp remains the umbrella path for full property-list semantics and cross-property conflict checking.

This reduces compile-time cost for kernel-language and JIT-style usage while preserving the full umbrella interface for users who need complete property-list behavior.

Measured header compile times:

• kernel_properties/function_properties.hpp: ~26 ms
• kernel_properties/function_launch_properties path: ~58 ms
• kernel_properties/properties.hpp umbrella: ~68 ms

[gmlueck]

I don't think we should call the header function_launch_properties. There are two distinct classes of kernel-related properties, which we call "kernel properties" and "kernel launch properties". The "kernel properties" are those that affect the way the kernel is compiled. For a normal kernel, you specify these via the get(properties_tag) function. For a free-function kernel, they are specified via the SYCL_EXT_ONEAPI_FUNCTION_PROPERTY macro. The "kernel launch properties" are those that affect the way the kernel is launched. These are specified via the launch_config parameter.

All the properties you list here are "kernel properties". Therefore, I think it would be confusing to put them in a header named "launch_properties". A logical breakdown of properties might be:

• free_function_properties.hpp: Just the single_task_kernel and nd_range_kernel properties along with the SYCL_EXT_ONEAPI_FUNCTION_PROPERTY macro.

• kernel_properties.hpp: The properties defined in sycl_ext_oneapi_kernel_properties, the property_tag type, and the SYCL_EXT_ONEAPI_FUNCTION_PROPERTY macro.

From your description, it sounds like error checking is a major contribution to the compilation time? If this is the case, could we add a macro that disables the error checking? This might be generally useful as a way to disable error checks in production code that has already been debugged.

Note that the max_work_group_size and max_linear_work_group_size properties are specific to CUDA. If these are causing compilations on Intel devices to be slow, we should do something to fix that. For example, they could be split out into a separate header.

[koparasy]

Thanks for the detailed feedback. I agree that the current function_launch_properties.hpp name is misleading, since the properties in that header are still compile-time kernel properties rather than "launch_config" properties.

My intent with the split was to separate the lightweight free-function annotation path from the heavier property machinery, not to introduce a new distinction between compile-time kernel properties and kernel launch properties. Given your point, I think the naming should better reflect that. One option I had in mind would be:

• function_properties.hpp for the minimal free-function annotation path single_task_kernel, nd_range_kernel SYCL_EXT_ONEAPI_FUNCTION_PROPERTY` macro.
• A second header with a name along the lines of function_kernel_properties.hpp or function_compile_properties.hpp for the broader set of compile-time kernel properties used on that path.

If that direction sounds reasonable to you, I can update the naming and documentation accordingly. I wanted to check with you first before changing it.

On the compile-time side, my current suspicion is that the main cost comes from the general property machinery and associated metaprogramming, rather than primarily from the diagnostics or error checking. I have not ruled the diagnostics out completely, but so far the evidence points more toward the property framework itself being the dominant factor.