[flang-commits] [clang] [flang] [clang][driver] When -fveclib=ArmPL flag is in use, always link against libamath (PR #116432)
Fangrui Song via flang-commits
flang-commits at lists.llvm.org
Mon Dec 9 20:03:13 PST 2024
================
@@ -490,6 +490,35 @@ void tools::AddLinkerInputs(const ToolChain &TC, const InputInfoList &Inputs,
else
A.renderAsInput(Args, CmdArgs);
}
+ if (const Arg *A = Args.getLastArg(options::OPT_fveclib)) {
+ const llvm::Triple &Triple = TC.getTriple();
+ StringRef V = A->getValue();
+ if (V == "ArmPL" && (Triple.isOSLinux() || Triple.isOSDarwin())) {
+ // To support -fveclib=ArmPL we need to link against libamath.
+ // Some of the libamath functions depend on libm, at the same time,
+ // libamath exports its own implementation of some of the libm
+ // functions. Since here we are interested only in the subset of
+ // libamath functions that is covered by the veclib mappings,
+ // we need to do the following:
+ //
+ // 1. On Linux, link only when actually needed.
+ //
+ // 2. Prefer libm functions over libamath.
+ //
+ // 3. Link against libm to resolve libamath dependencies.
+ //
+ if (Triple.isOSLinux()) {
+ CmdArgs.push_back(Args.MakeArgString("--push-state"));
+ CmdArgs.push_back(Args.MakeArgString("--as-needed"));
+ }
+ CmdArgs.push_back(Args.MakeArgString("-lm"));
----------------
MaskRay wrote:
If "It's a matter of prioritizing system-libm over libamath which contains faster (and potentially less accurate) implementations of some of the libm functions.", the comment above doesn't seem to mention this.
However, I am confused. Why cannot these duplicate symbols be removed from libamath so that the compiler driver doesn't have to play with circular -lm and -lamath dependency?
https://github.com/llvm/llvm-project/pull/116432
More information about the flang-commits
mailing list