[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