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

[Florian Hahn 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())
----------------
fhahn wrote:

Just trying to clarify the expected behavior, as it currently seems inconsistent. E.g. we vectorize `ilogbf` with ArmPL, but not `sin` without  `-fno-math-errno`: https://godbolt.org/z/xsGn1x5hd

At least on Linux, `ilogbf` may set errno (https://www.man7.org/linux/man-pages/man3/ilogb.3.html), so we should not vectorize with  `-fno-math-errno`, unless choosing ArmPL implies `-fno-math-errno` implicitly? 

If that is indeed the desired behavior, `ilogbf` should be marked as `readnone` (and we should drop the code here).

If that's not possible to do easily, the current change should be an OK start, but it should have a comment clearly stating which correctness issue is ignored for now

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