Page MenuHomePhabricator

DieGoldeneEnte (Holger Wünsche)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 15 2020, 2:28 AM (79 w, 4 d)

Recent Activity

Jan 21 2020

DieGoldeneEnte added a comment to D72903: [HIP] use GetProgramPath for executable discovery.

@hans: I would leave the decision to cherry-pick this into the 10 release to you. I think the change is nice to have, but once you know the problem, there exists an easy workaround (like symlinking the executables to the right directory).

Jan 21 2020, 10:29 AM · Restricted Project

Jan 17 2020

DieGoldeneEnte added a comment to D72903: [HIP] use GetProgramPath for executable discovery.

If @yaxunl has no objections, could someone merge this as I don't have commit access?
Also do we want to also apply this to older versions, since the change is trivial? I confirmed the same problem is in clang 8, 9 and 10 and am certain it is in clang 7, although I didn't test it, because I don't have appropriate device-libs at hand.

Jan 17 2020, 5:33 PM · Restricted Project
DieGoldeneEnte abandoned D72806: [HIP] fix paths for executables not in clang bin directory.

Adding the paths for llvm/lld is not needed, because GetProgramPath is actually also searching in $PATH. This means D72903 already is enough to fix my problem.

Jan 17 2020, 5:23 PM · Restricted Project
DieGoldeneEnte updated the diff for D72806: [HIP] fix paths for executables not in clang bin directory.

This patch now only adds the executable dirs to the program path, the code to search them is now in D72903.

Jan 17 2020, 12:59 AM · Restricted Project
DieGoldeneEnte updated the summary of D72806: [HIP] fix paths for executables not in clang bin directory.
Jan 17 2020, 12:52 AM · Restricted Project
DieGoldeneEnte created D72903: [HIP] use GetProgramPath for executable discovery.
Jan 17 2020, 12:52 AM · Restricted Project

Jan 16 2020

DieGoldeneEnte added a comment to D72806: [HIP] fix paths for executables not in clang bin directory.
In D72806#1825362, @tra 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.

Jan 16 2020, 3:34 PM · Restricted Project
DieGoldeneEnte updated the diff for D72806: [HIP] fix paths for executables not in clang bin directory.

The build doesn't fail anymore if lld is not present, also one can set LLD_BINARY_DIR manually. I also exchanged TOOLS_BINARY_DIR with LLVM_TOOLS_BINARY_DIR, since it is better readable and if compiled with llvm this is necessary to populate the variable (although the path is already present in that case, because clang and all the other utils should be in the same directory.

Jan 16 2020, 3:24 PM · Restricted Project
DieGoldeneEnte added a comment to D72806: [HIP] fix paths for executables not in clang bin directory.

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).

Jan 16 2020, 3:15 PM · Restricted Project

Jan 15 2020

DieGoldeneEnte created D72806: [HIP] fix paths for executables not in clang bin directory.
Jan 15 2020, 1:29 PM · Restricted Project