[PATCH] D84068: AMDGPU/clang: Search resource directory for device libraries

Matt Arsenault via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Aug 8 07:28:10 PDT 2020


arsenm added a comment.

In D84068#2159391 <https://reviews.llvm.org/D84068#2159391>, @tra wrote:

> Could you walk me through how you see this working in practice?
>
> IIUIC, the idea is to have bitcode files located somewhere within clang installation.

Yes

> If that's the case, will we ship those bitcode libraries with clang, or do they come from ROCm packages?

The rocm package will install symlinks into the clang resource directory. The rocm provided clang package should depend on the bitcode package

> If we ship them with clang, who/where/how builds them?
> If they come from ROCm packages, how would those packages add stuff into *clang* install directory? Resource dir is a rather awkward location if contents may be expected to change routinely.

Symlinks. I've been building the device libraries as part of LLVM_EXTERNAL_PROJECTS, and think this should be the preferred way to build and package the libraries. This is how compiler-rt is packaged on linux distributions. The compiler-rt binaries are a separate package symlinked into the resource directory locations. I'm not sure what you mean exactly by change routinely, the libraries should be an implementation detail invisible to users, not something they should be directly relying on. Only clang actually knows how to use them correctly and every other user is buggy

> What if I have multiple ROCm versions installed? Which one should provide the bitcode in the resource dir?

These should be treated as an integral part of clang, and not something to mix and match. Each rocm version should have its own copy of the device libraries. It only happens to work most of the time if you mismatch these, and this isn't a guaranteed property.

> As long as explicitly specified `--hip-device-lib-path` can still point to the right path, it's probably OK, but it all adds some confusion about who controls which parts of the HIP compilation and how it all is supposed to work in cases that deviate from the default assumptions.

Long term I would rather get rid of --hip-device-lib-path, and only use the standard -resource_dir flags

> It would help if the requirements would be documented somewhere.

Documentation would be good, but the problem I always have is deciding where "somewhere" is


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84068/new/

https://reviews.llvm.org/D84068



More information about the cfe-commits mailing list