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

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 23 06:56:27 PDT 2024


================
@@ -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())
----------------
fhahn 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

but as I said earlier, fixing this can be done as follow up

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


More information about the llvm-commits mailing list