rocm-device-libs for clang-16?
Hello,
I've been thinking about how to transition HIP from clang-15 to clang-16
(which will be necessary to enable support for RDNA 3 GPUs).
In retrospect, I think that omitting the LLVM version number from the
rocm-device-libs install path was a mistake. The amdgpu bitcode files
are only compatible within a single major version of LLVM. For example,
when the rocm-device-libs are built with clang 15.0.6, the resulting
bitcode files will be compatible clang 15.0.7. However, they are not
guaranteed to be compatible with clang 16.0.0.
If we update the rocm-device-libs to be built with clang-16, then it
might not be possible to use them with clang-15. Nevertheless, they will
still be installed in a path where clang-15 will find them. This may
result in confusing behaviour for any users that continue using clang-15
to build their projects. At the moment, we're also relying on a
Debian-specific patch to clang-15 to find the rocm-device-libs in
/usr/lib/$(multiarch)/amdgcn/bitcode and I'd rather not bring that patch
forward into clang-16.
Ideally, the rocm-device-libs would be installed to the clang resource
directory. This is where they are installed on Fedora [1] and it is
where they are planned to be placed in future versions of the upstream
ROCm project. It is also one of the default search locations for clang,
so we will be able to drop our patch. The problem is that if you run
`clang++-15 -print-resource-dir`, you'll find that on Debian the path is
`/usr/lib/llvm-15/lib/clang/15.0.7`. That path includes the LLVM patch
version and is therefore not stable. In Fedora, installing to that
location is probably easier because the LLVM resource directory is
/usr/lib64/clang/16.
Does anybody have thoughts on how we might move the rocm-device-libs
into the clang resource directory? Or, maybe on how to create a symlink
in the resource directory that points to a more stable rocm-device-libs
install path? Or, perhaps some way to create a system LLVM config file
[2] to do the same? I'm not sure of the best way to handle this, but I
think we're going to need to figure out a solution before we can move on
from clang-15.
Sincerely,
Cory Bloor
[1]:
https://packages.fedoraproject.org/pkgs/rocm-device-libs/rocm-device-libs/fedora-38-updates.html#files
[2]: https://clang.llvm.org/docs/UsersManual.html#configuration-files
Reply to: