Is it possible for dpc++ to support amd rocm？

[malixian]

Since ROCm does not support SPIRV, I want to try to use IR to compile the device code.
Is this feasible? How can I try it if it works？ Thanks very much.

[illuhad]

DPC++ does not currently support ROCm. You are already aware of hipSYCL which you can use to compile for ROCm and generate e.g. LLVM IR that targets ROCm.
AFAIK IR generated by DPC++ and targeted for SPIR-V cannot be compiled for ROCm in a straight-forward way, e.g. builtins and kernel entrypoint metadata are different.

Note that the opposite way might be possible soon, using hipSYCL to target DPC++ devices. More information to follow.

[malixian]

Thanks @illuhad, you mean that the IR generated(AFAIK IR) by dpc++ is not the standard LLVM IR? And can dpc++ generate standard llvm IR?

[illuhad]

My understanding is that while the LLVM IR as a language is always the same, there is no universal convention for the interface of device libraries which implement device builtins such as math functions. Similarly, how some metadata is expressed within LLVM IR (e.g. which functions are kernels i.e. program entrypoints, and which are just regular device functions) varies between toolchains. Because of this you usually cannot expect LLVM IR from the device pass of one toolchain to work with another toolchain.

Maybe one of the DPC++ developers can add more details regarding your second question.

EDIT: This is also not a DPC++ specific issue. You would have just the same problem when using the clang HIP driver to generate LLVM IR intended for ROCm and then try to compile it to nvptx.

[malixian]

Thanks for your reply @illuhad, I have a better understanding of this.

[MrSidims]

While (standard) LLVM IR is being generated by clang for DPCPP code the end goal for the compiler is SPIR-V. After clang generated a device module it's being translated to SPIR-V format (more details of a compiler's design is here). This format was chosen because SPIR-V is standardized and stable and it's easy to manipulate SPIR-V versions and add/exclude extensions depending whether a device can support them or note, while LLVM IR is much less stable and support of multiple devices (even for an only vendor) is complicated. So if a particular device's runtime supports SPIR-V (which is an open standard, used for example by OpenCL 2.0) - DPCPP compiler can be used for this device. May be there are some tips and tricks to make non-SPIR-V friendly devices working, but I'm not an expert in this area.

[keryell]

you mean that the IR generated (AFAIK IR) by dpc++ is not the standard LLVM IR? And can dpc++ generate standard llvm IR?

All this is open-source, so you can do whatever you want. :-)
For example https://github.com/triSYCL/sycl is a mix-and-match of DPC++ with some triSYCL spices to generate code for 2 non SPIR-V targets, Xilinx FPGA (LLVM IR with a SPIR 2.0 flavor) and Xilinx Versal ACAP AIE CGRA (pure LLVM IR). The Xilinx ACAP AIE side is not open-source yet because the architecture details and tooling are just getting out but this should come soon.
You can already get an idea of the Xilinx FPGA compile flow and adapt it to other targets.
For example starting from DPC++ and adding some hipSYCL spices... ;-)
Or just adapt the DPC++ CUDA runtime & compile flow to target ROCm/HIP instead of CUDA.