================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to