[SYCL] Allow specification of double GRF mode for SYCL

[sarnex]

This change extends Konst's work from #6182 to work for any SYCL kernel, not just ESIMD kernels

Basic summary of changes:

1. Move SYCL library set_kernel_properties function and related detail header out of esimd code into generic SYCL code
2. Generalize SYCLLowerESIMDKernelPropsPass to make it work for SYCL kernels
3. Change sycl-post-link module splitting to split non-ESIMD modules that have any number of double GRF kernels
4. Change program loader to add the "-ze-opt-large-register-file" option if the double GRF property is set. We do this instead of -doubleGRF because -doubleGRF only works for the VC backend, while -ze-opt-large-register-file works for both VC and scalar backends

Signed-off-by: Sarnie, Nick nick.sarnie@intel.com

[sarnex]

@steffenlarsen @kbobrovs @gmlueck Hey guys, here's the PR for the SYCL case if you're interested

[steffenlarsen]

Interesting! I am a little worried that with the current layout it may be confused with sycl_ext_oneapi_kernel_properties. Also, do we have an extension document for this?

[sarnex]

Interesting! I am a little worried that with the current layout it may be confused with sycl_ext_oneapi_kernel_properties. Also, do we have an extension document for this?

Thanks! I think this is only intended to be temporary until we can replace the implementation to use the extensions in your link. I don't know of any document (@kbobrovs correct me if im wrong). Please let me know if you'd like me to rename or move anything to ease confusion

[asudarsa]

@kbobrovs has mentioned in his PR about this change being a temporary solution: Quote: "This is temporary API until generic SYCL support for kernel properties is implemented:
https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/proposed/sycl_ext_oneapi_kernel_properties.asciidoc" Unquote.
Thanks

[asudarsa]

Do we need to move the E2E test as well? intel/llvm-test-suite#1033

[sarnex]

Do we need to move the E2E test as well? intel/llvm-test-suite#1033

So it looks like the E2E test was never merged, that PR is still open. I can submit a new one for this case if you think it has value

[kbobrovs]

I don't know of any document (@kbobrovs correct me if im wrong).

@sarnex, right, there is no document other than the API docs. @asudarsa is correct that this was considered temporary until better std solution is available.

[kbobrovs]

Mostly LGTM, with one typo and couple optional nits.

Also, E2E test for the feature should be added as well eventually into llvm-test-suite repo.
(I just revealed that my E2E test for ESIMD doubleGRF is still in open PR, will add it too)

[sarnex]

Mostly LGTM, with one typo and couple optional nits.

Also, E2E test for the feature should be added as well eventually into llvm-test-suite repo. (I just revealed that my E2E test for ESIMD doubleGRF is still in open PR, will add it too)

thanks, i will add an E2E test after this is merged based on your E2E test

[gmlueck]

@sarnex, right, there is no document other than the API docs. @asudarsa is correct that this was considered temporary until better std solution is available.

Just to make sure we are on the same page:

• We do not document this API to users
• We expect the only users of this API to be internal, and no end-user code will use it
• We reserve the right to remove support (and thus break ABI) at any time, even in a minor release

Agreed?

[sarnex]

@sarnex, right, there is no document other than the API docs. @asudarsa is correct that this was considered temporary until better std solution is available.

Just to make sure we are on the same page:

* We do not document this API to users

* We expect the only users of this API to be internal, and no end-user code will use it

* We reserve the right to remove support (and thus break ABI) at any time, even in a minor release

Agreed?

That is my understanding but I expect you were talking to @kbobrovs

[kbobrovs]

@sarnex, right, there is no document other than the API docs. @asudarsa is correct that this was considered temporary until better std solution is available.

Just to make sure we are on the same page:

* We do not document this API to users

* We expect the only users of this API to be internal, and no end-user code will use it

* We reserve the right to remove support (and thus break ABI) at any time, even in a minor release

Agreed?

That is my understanding but I expect you were talking to @kbobrovs

I agree

[asudarsa]

LGTM. Thanks Nick. Please keep a lookout from upcoming changes in this area.

[sarnex]

@pvchupin @AlexeySachkov Hey, I heard you guys are part of llvm-reviewers-runtime but I can't see who is part of it myself. Do you guys mind reviewing this or finding someone from there to review this? Thanks!

[pvchupin]

@sarnex, you can actually ping @intel/llvm-reviewers-runtime :)

[sarnex]

@sarnex, you can actually ping @intel/llvm-reviewers-runtime :)

Somehow it doesn't work for me, maybe a permissions thing? Weird

@intel/llvm-reviewers-runtime (see not highlighted)