The AMDGPU linker is lld, which has full support for standard features
like static libraries. Previously the AMDGPU toolchain did not forward
-L arguments so we could not tell it where to find certain libraries.
This patch simply forwards it like the other toolchains.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Driver/ToolChains/AMDGPU.cpp | ||
---|---|---|
546 ↗ | (On Diff #520017) | AddLinkerInputs has code doing that, and it handles env var LIBRARY_PATH. However that code is disabled for AMDGPU because AMDGPU returns true for isCrossCompiling. https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/CommonArgs.cpp#L236 It seems isCrossCompiling is solely for controlling whether to consume -L. If we want amdgpu toolchain to accept -L, we can simply let isCrossCompiling return false. |
clang/lib/Driver/ToolChains/AMDGPU.cpp | ||
---|---|---|
546 ↗ | (On Diff #520017) | Good catch, we could maybe set isCrossCompiling to false if targeted directly by the user, e.g. --target=amdgcn-amd-amdhsa vs --offload-arch. |
clang/lib/Driver/ToolChains/AMDGPU.cpp | ||
---|---|---|
546 ↗ | (On Diff #520017) | That would be better. Thanks. |
clang/lib/Driver/ToolChains/AMDGPU.cpp | ||
---|---|---|
546 ↗ | (On Diff #520017) | It still is technically cross compiling, since we are building for a target that does not match the system's architecture. The original code that prevents passing -L was contributed by @MaskRay. I understand that we may not want to pass LIBRARY_PATH defines, but what's the rationale for not passing any -L options manually specified by the user? |
clang/lib/Driver/ToolChains/AMDGPU.cpp | ||
---|---|---|
546 ↗ | (On Diff #520017) | The LIBRARY_PATH code had been there when I moved it in 2019. It'd be best not to rely on LIBRARY_PATH. I think that forwarding -L seems reasonable but I am not familiar with the amdgpu ecosystem.. |
clang/lib/Driver/ToolChains/AMDGPU.cpp | ||
---|---|---|
546 ↗ | (On Diff #520017) | The linker is just lld so it should be the same conceptually. I'm just figuring that even if the user is cross compiling we should respect -L passed on the command line. Should I change this patch to make that change? |
The linker is just lld so it should be the same conceptually. I'm just figuring that even if the user is cross compiling we should respect -L passed on the command line. Should I change this patch to make that change?
So it seems that there are configurations that we need -L (cross compilation?). If we forward -L in some configurations, I think it'd be better to do this consistently.
The LIBRARY_PATH options seems not useful and the conditional if (not cross compiling) add LIBRARY_PATH is more unfortunate. I wish that we don't add more cases that we do something with LIBRARY_PATH.
(IMO the LIBRARY_PATH users can just fix their build system or use CCC_OVERRIDE_OPTIONS)
We definitely want to avoid more uses of TC.isCrossCompiling(). Most parts of the driver are written in a way that is TC.isCrossCompiling() agnostic.
The comment itself // LIBRARY_PATH are included before user inputs and only supported on native toolchains. suggests that something like this might be valid.
// LIBRARY_PATH are included before user inputs and only supported on native // toolchains. if (!TC.isCrossCompiling()) addDirectoryList(Args, CmdArgs, "-L", "LIBRARY_PATH"); else Args.AddAllArgs(CmdArgs, options::OPT_L);
clang/lib/Driver/ToolChains/AMDGPU.cpp | ||
---|---|---|
546 ↗ | (On Diff #520017) | For offloading I think the problem might be that we don't want to forward -L arguments from the host. In that case, we might be able to apply ` |
Sorry, but I just realized that updating CommonArgs.cpp is wrong... I have fixed it with commit 681cb54a54bb60dea9034b4b0b45ccc392875b9a.