================
@@ -4562,7 +4565,15 @@ void Driver::BuildDefaultActions(Compilation &C,
DerivedArgList &Args,
LA->propagateHostOffloadInfo(C.getActiveOffloadKinds(),
/*BoundArch=*/nullptr);
} else {
- LA = C.MakeAction<LinkJobAction>(LinkerInputs, types::TY_Image);
+ // If we are linking but were passed -emit-llvm, we will be calling
+ // llvm-link, so set the output type accordingly. This is only allowed in
+ // rare cases, so make sure we aren't going to error about it.
+ bool LinkingIR = Args.hasArg(options::OPT_emit_llvm) &&
----------------
mgcarrasco wrote:
Thanks @sarnex. I thought that this PR's changes were changing the
functionality for the SPIRV toolchain (`ToolChains/SPIRV.cpp`) only and not any
of those of AMDGPU. I assumed this because the new test cases
(`spirv-llvm-link-emit-asm.c` and `spirv-llvm-link.c`) are not testing the
AMDGPU toolchains. The changes in the other test cases were only to change the
order of `llvm-link` arguments. Is the intent to change the behavior of the
AMDGPU toolchains?
I understand that independently of the driver changes, for refactoring
purposes, the `llvm-link` invoking code is being unified --- which I think it
is a good idea if that is the way to go.
https://github.com/llvm/llvm-project/pull/169572
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
