[SPIRV] Properly discover LLVM tools that live next to the compiler

[jhuber6]

Summary:
When we compile with -emit-llvm it will try to use llvm-link. The
toolchain does not properly add the driver directory as a valid path so
this will default to the user's search path. This, like other tools,
should prioritize the binaries living next to the compiler.

Side note, why is this not default behavior?

[llvmbot]

@llvm/pr-subscribers-clang
@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-backend-spir-v

Author: Joseph Huber (jhuber6)

Changes

Summary:
When we compile with -emit-llvm it will try to use llvm-link. The
toolchain does not properly add the driver directory as a valid path so
this will default to the user's search path. This, like other tools,
should prioritize the binaries living next to the compiler.

Side note, why is this not default behavior?

---

Full diff: https://github.com/llvm/llvm-project/pull/178779.diff

1 Files Affected:

• (modified) clang/lib/Driver/ToolChains/SPIRV.cpp (+3)

diff --git a/clang/lib/Driver/ToolChains/SPIRV.cpp b/clang/lib/Driver/ToolChains/SPIRV.cpp
index 81fd2afc6e9c7..c1ccb1e7d8508 100644
--- a/clang/lib/Driver/ToolChains/SPIRV.cpp
+++ b/clang/lib/Driver/ToolChains/SPIRV.cpp
@@ -172,6 +172,9 @@ SPIRVToolChain::SPIRVToolChain(const Driver &D, const llvm::Triple &Triple,
   // TODO: Revisit need/use of --sycl-link option once SYCL toolchain is
   // available and SYCL linking support is moved there.
   NativeLLVMSupport = Args.hasArg(options::OPT_sycl_link);
+
+  // Lookup binaries into the driver directory.
+  getProgramPaths().push_back(getDriver().Dir);
 }
 
 bool SPIRVToolChain::HasNativeLLVMSupport() const { return NativeLLVMSupport; }

[jdoerfert]

Can you add a test? Otherwise, this seems sensible.

[jhuber6]

Can you add a test? Otherwise, this seems sensible.

Not sure off of the top of my head how you'd test this, since in the test environments the path is going to point to the build's binary directory anyways AFAIK.

[jdoerfert]

Can you add a test? Otherwise, this seems sensible.

Not sure off of the top of my head how you'd test this, since in the test environments the path is going to point to the build's binary directory anyways AFAIK.

Hmm... Let me verify it solves the build issue of the device runtime and then we go ahead as is.

[jdoerfert]

This makes the SPIRV OpenMP device runtime build succeed even if the PATH llvm-link is old.