[flang-commits] [clang] [flang] [clang][driver] When -fveclib=ArmPL flag is in use, always link against libamath (PR #116432)

[Paul Osmialowski via flang-commits]

================
@@ -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"));
----------------
pawosm-arm 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.
> 

Now it mentions.

> 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?
> 
> If the reason is that we want to support both old libm and new libm where libm contains faster implementations also in libamath, I expect this reasoning to be covered.

This is purely historical reason. Libamath was meant to be libm replacement, being veclib provider for fveclib=ArmPL just one more role of this lib. The user still needs to be able to specify `-lamath` to be able to choose those less accurate faster functions, and I've made this covered by now added extra checks in the test cases.


https://github.com/llvm/llvm-project/pull/116432