[PATCH] D72806: [HIP] fix paths for executables not in clang bin directory

Holger Wünsche via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jan 16 15:34:10 PST 2020


DieGoldeneEnte added a comment.

In D72806#1825362 <https://reviews.llvm.org/D72806#1825362>, @tra wrote:

> In D72806#1825333 <https://reviews.llvm.org/D72806#1825333>, @DieGoldeneEnte wrote:
>
> > In D72806#1824560 <https://reviews.llvm.org/D72806#1824560>, @yaxunl wrote:
> >
> > > What's the use case of this change?
> > >
> > > Normally clang needs to call opt/llc/lld from the same directory of clang. Why do we need to find them in other directories?
> >
> >
> > My motivation is the nix-package manager, which has llvm, lld and clang in different packages (which results in different directories).
>
>
> We've had similar issues with use of clang for CUDA on Debian (I think), where CUDA was scattered all over the place.
>  The way to do it was to create a 'shim' directory structure which would put all relevant tools in the right places.
>  Something similar could be done in your case -- make a package which would depend on individual tool packages and which would symlink all of them into one dir and point your compiler there.


That's what I will do if we don't fix this here. But I think it would be cleaner if one can set the directories.

Even in case we don't add the extra directories for llvm and lld, it would be a good idea to use the getProgramPath function instead of building it manually (so only the changes in HIP.cpp except lines 273-282). This was planned anyways according to the comments in HIP.cpp line 270-271:

>   // Lookup binaries into the driver directory, this is used to
>   // discover the clang-offload-bundler executable.




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

https://reviews.llvm.org/D72806





More information about the cfe-commits mailing list