[llvm] [LAA] Don't assume libcalls with output/input pointers can be vectorized (PR #108980)

[Benjamin Maxwell via llvm-commits]

================
@@ -2449,13 +2449,20 @@ bool LoopAccessInfo::analyzeLoop(AAResults *AA, const LoopInfo *LI,
         continue;
 
       // If this is a load, save it. If this instruction can read from memory
-      // but is not a load, then we quit. Notice that we don't handle function
-      // calls that read or write.
+      // but is not a load, we only allow it if it's a call to a function with a
+      // vector mapping and no pointer arguments.
       if (I.mayReadFromMemory()) {
-        // If the function has an explicit vectorized counterpart, we can safely
-        // assume that it can be vectorized.
+        auto hasPointerArgs = [](CallBase *CB) {
+          return any_of(CB->args(), [](Value const *Arg) {
+            return Arg->getType()->isPointerTy();
+          });
+        };
+
+        // If the function has an explicit vectorized counterpart, and does not
+        // take output/input pointers, we can safely assume that it can be
+        // vectorized.
         if (Call && !Call->isNoBuiltin() && Call->getCalledFunction() &&
-            !VFDatabase::getMappings(*Call).empty())
+            !hasPointerArgs(Call) && !VFDatabase::getMappings(*Call).empty())
----------------
MacDue wrote:

> It would still be good to know if there is any justification for vectorizing cases with custom veclibs for functions that may access errno

`-fveclib` has to be intentionally set by the user, which means they probably know what they're doing, and would like to force the use of the vector library calls (so don't care about `errno`). So one possible path forward is to move this check from under `mayReadFromMemory()` and allow it to apply more generally. This may also require updating the documentation of `-fveclib` to state this is intentional. 

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