[SYCL][DOC] Propose "get_kernel_info" extension

[gmlueck]

Add a proposed extension to query a kernel's information descriptor without creating a kernel bundle.

[steffenlarsen]

Which exceptions are these, specifically?

[gmlueck]

For example:

Preconditions: [...] The device dev must be one of the devices contained by ctxt. The kernel KernelName must be compatible with the device dev as defined by is_compatible.

In the existing SYCL 2020 spec, these error conditions mandate an exception:

• An exception with the errc::invalid error code if any of the devices in devs is not one of devices contained by the context ctxt or is not a descendent device of some device in ctxt.

• An exception with the errc::invalid error code if the kernel is not compatible with device dev (as defined by is_compatible())

[Pennycook]

Actually enqueuing the kernel would still throw one of these exceptions though, right?

[gmlueck]

This PR only adds query functions, so nothing in this PR would change the behavior when enqueuing a kernel.

My comment about "in retrospect", though, might change the behavior when enqueuing a kernel. I do feel that we went too far in the core SYCL spec about mandating exceptions for error conditions. This requires an implementation to check the function inputs and throw a specific exception. I'm not sure we want to mandate those error checks, especially for functions that are likely to be on an application's critical path. If we did not mandate the error checks, an implementation might just assume they are correct, and you get what you get if they are not. This might be a confusing error from a lower-level software layer, a crash, or even code that runs incorrectly.

Of course, an implementation could still perform these error checks. DPC++ could decide to do this by default if the cost isn't high. Or, DPC++ could provide a compiler option to enable them if they are expensive.

[Pennycook]

Of course, an implementation could still perform these error checks. DPC++ could decide to do this by default if the cost isn't high. Or, DPC++ could provide a compiler option to enable them if they are expensive.

Are we allowed to go the other way?

There are already some cases (e.g., math) where a user can opt-in to disabling features required by the specification (e.g., certain NaN handling) in pursuit of performance. As long as DPC++ provides a mode that is conformant to the required errors, is it legal to also provide something like an -fsycl-no-exceptions option (and maybe even enable it by default)?

If what I describe above is legal, I think I'd prefer it to adding more UB into the specification. Developers are already used to implementations providing options that improve performance, and specifying required exceptions guarantees that any conformant implementation will provide some configuration in which it's possible to get the safe behavior.

[gmlueck]

I think it would be possible, but it seems contrary to the way C++ is specified. Most C++ library functions have a precondition that their arguments are correct. It's not common for C++ to mandate an error check.

[steffenlarsen]

Seems like the specification currently uses precondition for template argument requirements, so I think precondition is fine.

[gmlueck]

Seems like the specification currently uses precondition for template argument requirements

In the current SYCL 2020 specification, you mean? Yes, this is a bug in the specification, and it's my fault. I wrote that part of the specification before I understood the difference between Preconditions and Constraints. Those should be Constraints. It's on my list of things to clean up.

[gmlueck]

@steffenlarsen have your concerns been resolved? I think @Pennycook's latest comments are related to the core SYCL spec, not this PR, so we can resolve them offline.

[steffenlarsen]

Yes! Let's roll with it. 🪨

[gmlueck]

@intel/llvm-gatekeepers I think this is ready to merge.