[SYCL] Implement loading SYCLBIN into kernel_bundle

[steffenlarsen]

This commit implements the functionality for loading SYCLBIN files into kernel bundles. This is done by mimicking the structure of regular device binaries, then letting the existing functionality handle compiling and linking.

This implements part of the sycl_ext_oneapi_syclbin extension.

Note that parts of this implementation uses functionality copied from LLVMSupport and LLVMObject. Eventually they should be replaced in favor of using the LLVM libraries directly.

[jopperm]

Looks super neat, just two nits and a question:

You don't seem to go through ProgramManager::addImage/removeImages for SYCLBINs -- do you still get support for eliminated arguments, and are the PM's datastructures cleaned when a SYCLBIN kernel bundle is destroyed?

[steffenlarsen]

You don't seem to go through ProgramManager::addImage/removeImages for SYCLBINs -- do you still get support for eliminated arguments, and are the PM's datastructures cleaned when a SYCLBIN kernel bundle is destroyed?

Good question! I intentionally didn't want to go through addImages/removeImages to avoid the program manager being too aware of the contents of the binaries. I wanted kernel_bundle and device image structures to be the primary owners of the binaries. Looking at the parts that removeImages clean up, I definitely need to investigate whether the eliminated args mask and the device global variables work here. Maybe we can refactor their registration.

[cperkinsintel]

Don't these need an #else ? What will happen if the compiler doesn't have filesystem or span? IIRC, we are still trying to support GCC 7.5 whose support of C++17 filesystem feature is not complete. Take a look at what is done in os_util.cpp, where the fallback includes experimental/filesystem.

Also, std::span is C++20, iirc. But we have sycl::span , so maybe use that?

OR if I'm operating on yesterdays information and this is no longer a problem, let me know.