[SYCL][Docs] Implement compile and link for source-based kernel bundles

[steffenlarsen]

Implements a new compile variant for source-based kernel_bundle and the corresponding linking functionality.

[steffenlarsen]

Built on #17380.

[jopperm]

Two questions pertaining to the potential non-uniqueness of symbol names in the context of RTC (e.g., application compiling multiple source strings with the same kernel/function names).

[gmlueck]

The corresponding error for build is:

An exception with the errc::invalid error code if the source language lang does not support one of the properties in PropertyListT or if props contains a build_options property that contains an option that is not supported by lang.

Is there a reason the wording here isn't the same? Did you intend to rename build_options to options, or was that just a typo?

[steffenlarsen]

I was contemplating adding a separate option property or renaming the existing one, but I worried it would just grow the current addition too much for a single change. What do we think is best here? Are we happy with it being build_options? Do we rename? Should we have a separate compile_options to make it easier to separate the valid input and do any potential checks?

[gmlueck]

There is no similar restriction for build. Is there a reason we need this restriction for compile? Can we not compile other languages like OpenCL or SPIR-V?

It seems weird to list the sycl language specifically here. Should we instead split the query ext_oneapi_can_compile into two queries (for compile and build)? Or, do you think the limitation with sycl is only temporary, and that's why you didn't add a query?

The whole business about join seems like a can of worms. As you allude, the application could joint two source bundles from different languages! I think it's better to avoid the whole can of worms by adding a constraint to join, preventing it from joining bundles of source state.

[steffenlarsen]

There is no similar restriction for build. Is there a reason we need this restriction for compile? Can we not compile other languages like OpenCL or SPIR-V?

I believe we could relax this restriction to allow compiling OpenCL, SPIR-V, etc, but by allowing these source languages in object state complicates the logic for linking a little, as we wouldn't know their imported/exported symbols. There are ways we could solve that, but since my focus was on SYCL RTC kernel bundles in this initial variant, I elected to disallow them for now.

It seems weird to list the sycl language specifically here. Should we instead split the query ext_oneapi_can_compile into two queries (for compile and build)? Or, do you think the limitation with sycl is only temporary, and that's why you didn't add a query?

I did not consider splitting ext_oneapi_can_compile. I think it would make sense (unless we know we want to expand the above and don't think there will be cases where a target can build but not compile,) but since it would be ext_oneapi_can_compile for compile we have to repurpose the one we already have and probably change the uses of it around existing code. Would it make sense to do this in a follow-up for the sake of change granularity?

The whole business about join seems like a can of worms. As you allude, the application could joint two source bundles from different languages! I think it's better to avoid the whole can of worms by adding a constraint to join, preventing it from joining bundles of source state.

I'm still not sure it's necessarily that big a can of worms. I agree, the wording here is a little awkward because of there not currently being any restrictions on join and I think it might make sense to at least specify that joining kernel bundles in source state must be of the same state. Logically that makes sense in my head, as I think the source language of a source state bundle is intrinsic to it. I would be happy to sketch up some wording for a section describing the behavior of join with source state bundles. 😄