-
Notifications
You must be signed in to change notification settings - Fork 15.1k
[HIP] Hack around CMake incorrectly parsing OpenMP support in HIP mode #164482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Summary: The new driver uses an embedded clang job to handle the device compilation. This correctly returns the linker as being `ld.lld`. The CMake parser to detect things like OpenMP support in the linker will parse the output of `-v` for the linker job. If the user is also using LLD for their linker, it will think this job is the linker and then fail as it does not see the required libraries. For these special HIP copmilations, just print the linker wrapper invocation and nothing else. This will still show users the steps used to generate the binary but it will hack around this issue.
|
@llvm/pr-subscribers-clang-driver @llvm/pr-subscribers-clang Author: Joseph Huber (jhuber6) ChangesSummary: Full diff: https://github.com/llvm/llvm-project/pull/164482.diff 2 Files Affected:
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp
index a7310ba2da061..caf74786aebea 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -9099,6 +9099,9 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
};
auto ShouldForward = [&](const llvm::DenseSet<unsigned> &Set, Arg *A,
const ToolChain &TC) {
+ // CMake hack to avoid printing verbose informatoin for HIP non-RDC mode.
+ if (A->getOption().matches(OPT_v) && JA.getType() == types::TY_Object)
+ return false;
return (Set.contains(A->getOption().getID()) ||
(A->getOption().getGroup().isValid() &&
Set.contains(A->getOption().getGroup().getID()))) &&
@@ -9174,7 +9177,12 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
CmdArgs.push_back(
Args.MakeArgString("--host-triple=" + getToolChain().getTripleString()));
- if (Args.hasArg(options::OPT_v))
+
+ // CMake hack, suppress passing verbose arguments for the special-case HIP
+ // non-RDC mode compilation. This confuses default CMake implicit linker
+ // argument parsing when the language is set to HIP and the system linker is
+ // also `ld.lld`.
+ if (Args.hasArg(options::OPT_v) && JA.getType() != types::TY_Object)
CmdArgs.push_back("--wrapper-verbose");
if (Arg *A = Args.getLastArg(options::OPT_cuda_path_EQ))
CmdArgs.push_back(
diff --git a/clang/test/Driver/hip-toolchain-no-rdc.hip b/clang/test/Driver/hip-toolchain-no-rdc.hip
index 2f40fd478671e..840334e19e7f2 100644
--- a/clang/test/Driver/hip-toolchain-no-rdc.hip
+++ b/clang/test/Driver/hip-toolchain-no-rdc.hip
@@ -214,3 +214,10 @@
// AMDGCNSPIRV: {{".*clang-offload-bundler.*"}} "-type=o"
// AMDGCNSPIRV-SAME: "-targets={{.*}}hipv4-spirv64-amd-amdhsa--amdgcnspirv,hipv4-amdgcn-amd-amdhsa--gfx900"
// AMDGCNSPIRV-SAME: "-input=[[AMDGCNSPV_CO]]" "-input=[[GFX900_CO]]"
+
+// Check verbose printing with the new driver.
+// RUN: %clang -### --target=x86_64-linux-gnu -fno-gpu-rdc -nogpulib -nogpuinc \
+// RUN: --offload-new-driver --offload-arch=gfx908 -v %s 2>&1 | FileCheck %s --check-prefix=VERBOSE
+// VERBOSE: clang-linker-wrapper
+// VERBOSE-NOT: --device-compiler=amdgcn-amd-amdhsa=-v
+// VERBOSE-NOT: --wrapper-verbose
|
llvm#164482) Summary: The new driver uses an embedded clang job to handle the device compilation. This correctly returns the linker as being `ld.lld`. The CMake parser to detect things like OpenMP support in the linker will parse the output of `-v` for the linker job. If the user is also using LLD for their linker, it will think this job is the linker and then fail as it does not see the required libraries. For these special HIP compilations, just print the linker wrapper invocation and nothing else. This will still show users the steps used to generate the binary but it will hack around this issue.
llvm#164482) Summary: The new driver uses an embedded clang job to handle the device compilation. This correctly returns the linker as being `ld.lld`. The CMake parser to detect things like OpenMP support in the linker will parse the output of `-v` for the linker job. If the user is also using LLD for their linker, it will think this job is the linker and then fail as it does not see the required libraries. For these special HIP compilations, just print the linker wrapper invocation and nothing else. This will still show users the steps used to generate the binary but it will hack around this issue.
llvm#164482) Summary: The new driver uses an embedded clang job to handle the device compilation. This correctly returns the linker as being `ld.lld`. The CMake parser to detect things like OpenMP support in the linker will parse the output of `-v` for the linker job. If the user is also using LLD for their linker, it will think this job is the linker and then fail as it does not see the required libraries. For these special HIP compilations, just print the linker wrapper invocation and nothing else. This will still show users the steps used to generate the binary but it will hack around this issue.
llvm#164482) Summary: The new driver uses an embedded clang job to handle the device compilation. This correctly returns the linker as being `ld.lld`. The CMake parser to detect things like OpenMP support in the linker will parse the output of `-v` for the linker job. If the user is also using LLD for their linker, it will think this job is the linker and then fail as it does not see the required libraries. For these special HIP compilations, just print the linker wrapper invocation and nothing else. This will still show users the steps used to generate the binary but it will hack around this issue.
Summary:
The new driver uses an embedded clang job to handle the device
compilation. This correctly returns the linker as being
ld.lld. TheCMake parser to detect things like OpenMP support in the linker will
parse the output of
-vfor the linker job. If the user is also usingLLD for their linker, it will think this job is the linker and then fail
as it does not see the required libraries. For these special HIP
compilations, just print the linker wrapper invocation and nothing else.
This will still show users the steps used to generate the binary but it
will hack around this issue.