[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