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