================
@@ -9909,9 +9909,14 @@ void LinkerWrapper::ConstructJob(Compilation &C, const
JobAction &JA,
}
// If the user explicitly requested it via `--offload-arch` we should
- // extract it from any static libraries if present.
- for (StringRef Arg : ToolChainArgs.getAllArgValues(OPT_offload_arch_EQ))
- CmdArgs.emplace_back(Args.MakeArgString("--should-extract=" + Arg));
+ // extract it from any static libraries if present. Use the canonical
+ // name, which device images are labeled with.
+ if (ToolChainArgs.hasArg(OPT_offload_arch_EQ))
----------------
srividya-sundaram wrote:
Yes, that's the issue.
The offload packager labels each device image with the target ID from
getOffloadArchs.
getOffloadArchs sorts the features, so gfx908:xnack+:sramecc- becomes
gfx908:sramecc-:xnack+, and it applies --no-offload-arch
--should-extract was copied straight from --offload-arch.
So the --should-extract values didn't match the device image labels when the
features weren't sorted, and target IDs removed with --no-offload-arch were
still requested.
Now both come from getOffloadArchs, and I reworded the comment so it doesn't
say "canonical name"
AFAIC, It isn't cached: getOffloadArchs builds a new list on every call, and
nothing stores it.
So this follows the existing pattern, but it does mean --offload-arch=native
runs GPU detection again. If caching the target ID list per toolchain on
Compilation makes sense to you, can that be done in a follow-up PR?
https://github.com/llvm/llvm-project/pull/232148
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
