[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 seems like the intention with this check was that if you have a vector mapping -> vectorize the call (regardless of the function attributes). It's not clear why it's gated under `mayReadFromMemory()` (there does not seem to be an explanation in the original patch: https://reviews.llvm.org/D8095).

The pointer arguments issue is a separate issue (which did not occur earlier as outside ArmPL/SLEEF there's no mapping for functions with output pointers).   

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