[clang] [clang][Driver][SPIR-V] Allow linking IR using llvm-link (PR #169572)

[Manuel Carrasco via cfe-commits]

================
@@ -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:

Ty again. I'm very sorry if I'm missing something. I'm confused because if `-hip-link` was present and working for AMDGPU TCs before this PR and the only functional change is for `ToolChains/SPIRV.cpp`, why the need to check for `C.getDefaultToolChain().getTriple().isAMDGPU()` to set ` types::TY_LLVM_BC`?

Prior these changes, any compilation path that arrived to that point set `types::TY_Image`. I'm missing why the cases that evaluate `C.getDefaultToolChain().getTriple().isAMDGPU()`  to true now have to set `types::TY_LLVM_BC` when they didn't need it before.

I was expecting a more restricting check that excludes AMDGPU TCs actually since the intent is not to affect them. For example, `clang --offload-arch=amdgcnspirv`  won't use `ToolChains/SPIRV.cpp` and the PR's intent is not to change that, right? 

https://github.com/llvm/llvm-project/pull/169572