Skip to content

Conversation

@kasuga-fj
Copy link
Contributor

tryDelinearizeFixedSizeImpl is a heuristic function relying on GEP's type information. Using these information to drive an optimization heuristic is not allowed, so this function should be removed. As #161822 and #164798 have eliminated all calls to this, this patch removes the function itself.

@llvmbot llvmbot added the llvm:analysis Includes value tracking, cost tables and constant folding label Nov 21, 2025
@llvmbot
Copy link
Member

llvmbot commented Nov 21, 2025

@llvm/pr-subscribers-llvm-analysis

Author: Ryotaro Kasuga (kasuga-fj)

Changes

tryDelinearizeFixedSizeImpl is a heuristic function relying on GEP's type information. Using these information to drive an optimization heuristic is not allowed, so this function should be removed. As #161822 and #164798 have eliminated all calls to this, this patch removes the function itself.


Full diff: https://github.com/llvm/llvm-project/pull/169046.diff

2 Files Affected:

  • (modified) llvm/include/llvm/Analysis/Delinearization.h (-11)
  • (modified) llvm/lib/Analysis/Delinearization.cpp (-38)
diff --git a/llvm/include/llvm/Analysis/Delinearization.h b/llvm/include/llvm/Analysis/Delinearization.h
index 434cfb61699d6..cdcc3b67fccf1 100644
--- a/llvm/include/llvm/Analysis/Delinearization.h
+++ b/llvm/include/llvm/Analysis/Delinearization.h
@@ -155,17 +155,6 @@ bool getIndexExpressionsFromGEP(ScalarEvolution &SE,
                                 SmallVectorImpl<const SCEV *> &Subscripts,
                                 SmallVectorImpl<int> &Sizes);
 
-/// Implementation of fixed size array delinearization. Try to delinearize
-/// access function for a fixed size multi-dimensional array, by deriving
-/// subscripts from GEP instructions. Returns true upon success and false
-/// otherwise. \p Inst is the load/store instruction whose pointer operand is
-/// the one we want to delinearize. \p AccessFn is its corresponding SCEV
-/// expression w.r.t. the surrounding loop.
-bool tryDelinearizeFixedSizeImpl(ScalarEvolution *SE, Instruction *Inst,
-                                 const SCEV *AccessFn,
-                                 SmallVectorImpl<const SCEV *> &Subscripts,
-                                 SmallVectorImpl<int> &Sizes);
-
 struct DelinearizationPrinterPass
     : public PassInfoMixin<DelinearizationPrinterPass> {
   explicit DelinearizationPrinterPass(raw_ostream &OS);
diff --git a/llvm/lib/Analysis/Delinearization.cpp b/llvm/lib/Analysis/Delinearization.cpp
index 4064b25d9d4e7..8a8c2277012ec 100644
--- a/llvm/lib/Analysis/Delinearization.cpp
+++ b/llvm/lib/Analysis/Delinearization.cpp
@@ -704,44 +704,6 @@ bool llvm::getIndexExpressionsFromGEP(ScalarEvolution &SE,
   return !Subscripts.empty();
 }
 
-bool llvm::tryDelinearizeFixedSizeImpl(
-    ScalarEvolution *SE, Instruction *Inst, const SCEV *AccessFn,
-    SmallVectorImpl<const SCEV *> &Subscripts, SmallVectorImpl<int> &Sizes) {
-  Value *SrcPtr = getLoadStorePointerOperand(Inst);
-
-  // Check the simple case where the array dimensions are fixed size.
-  auto *SrcGEP = dyn_cast<GetElementPtrInst>(SrcPtr);
-  if (!SrcGEP)
-    return false;
-
-  getIndexExpressionsFromGEP(*SE, SrcGEP, Subscripts, Sizes);
-
-  // Check that the two size arrays are non-empty and equal in length and
-  // value.
-  // TODO: it would be better to let the caller to clear Subscripts, similar
-  // to how we handle Sizes.
-  if (Sizes.empty() || Subscripts.size() <= 1) {
-    Subscripts.clear();
-    return false;
-  }
-
-  // Check that for identical base pointers we do not miss index offsets
-  // that have been added before this GEP is applied.
-  Value *SrcBasePtr = SrcGEP->getOperand(0)->stripPointerCasts();
-  const SCEVUnknown *SrcBase =
-      dyn_cast<SCEVUnknown>(SE->getPointerBase(AccessFn));
-  if (!SrcBase || SrcBasePtr != SrcBase->getValue()) {
-    Subscripts.clear();
-    return false;
-  }
-
-  assert(Subscripts.size() == Sizes.size() + 1 &&
-         "Expected equal number of entries in the list of size and "
-         "subscript.");
-
-  return true;
-}
-
 namespace {
 
 void printDelinearization(raw_ostream &O, Function *F, LoopInfo *LI,

@kasuga-fj kasuga-fj force-pushed the remove-gep-based-delinearization branch from 6165aeb to 217d866 Compare November 21, 2025 14:50
@kasuga-fj kasuga-fj requested review from Meinersbur and sjoerdmeijer and removed request for Meinersbur November 21, 2025 15:27
@github-actions
Copy link

🐧 Linux x64 Test Results

  • 186454 tests passed
  • 4865 tests skipped

@sjoerdmeijer sjoerdmeijer requested a review from sebpop November 25, 2025 15:24
Copy link
Collaborator

@sjoerdmeijer sjoerdmeijer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM

@sebpop pointed one thing out to me offline: maybe Polly test cases need fixing up.
@Meinersbur: what is the policy around this? Should that be part of this patch? Or done separately?

@kasuga-fj
Copy link
Contributor Author

Polly uses getIndexExpressionsFromGEP, which is different from tryDelinearizeFixedSizeImpl. So this PR should not affect Polly test cases. We also should remove getIndexExpressionsFromGEP in the future, and it needs to update Polly test cases, which Michael is working on (#164798 (review))

@sjoerdmeijer
Copy link
Collaborator

Polly uses getIndexExpressionsFromGEP, which is different from tryDelinearizeFixedSizeImpl. So this PR should not affect Polly test cases. We also should remove getIndexExpressionsFromGEP in the future, and it needs to update Polly test cases, which Michael is working on (#164798 (review))

Ok, great, then you can just go ahead and merge this I think.

Copy link
Member

@Meinersbur Meinersbur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Polly not affected (you would see that in the pre-merge CI failing)

Working on removing getIndexExpressionsFromGEP from Polly. The problem I encountered is that the matrix-multiplication pattern recognition relies on multi-dimensional accesses. Detecting the pattern with linearized accesses is not so easy.

@kasuga-fj kasuga-fj enabled auto-merge (squash) November 26, 2025 12:24
@kasuga-fj kasuga-fj merged commit 2b8d363 into llvm:main Nov 26, 2025
7 of 9 checks passed
@kasuga-fj kasuga-fj deleted the remove-gep-based-delinearization branch November 26, 2025 12:51
tanji-dg pushed a commit to tanji-dg/llvm-project that referenced this pull request Nov 27, 2025
`tryDelinearizeFixedSizeImpl` is a heuristic function relying on GEP's
type information. Using these information to drive an optimization
heuristic is not allowed, so this function should be removed. As llvm#161822
and llvm#164798 have eliminated all calls to this, this patch removes the
function itself.
GeneraluseAI pushed a commit to GeneraluseAI/llvm-project that referenced this pull request Nov 27, 2025
`tryDelinearizeFixedSizeImpl` is a heuristic function relying on GEP's
type information. Using these information to drive an optimization
heuristic is not allowed, so this function should be removed. As llvm#161822
and llvm#164798 have eliminated all calls to this, this patch removes the
function itself.
@sebpop
Copy link
Contributor

sebpop commented Nov 28, 2025

the matrix-multiplication pattern recognition relies on multi-dimensional accesses. Detecting the pattern with linearized accesses is not so easy.

I have fixed all Polly tests with reading the array info from global or alloca dimensions:
#156342

augusto2112 pushed a commit to augusto2112/llvm-project that referenced this pull request Dec 3, 2025
`tryDelinearizeFixedSizeImpl` is a heuristic function relying on GEP's
type information. Using these information to drive an optimization
heuristic is not allowed, so this function should be removed. As llvm#161822
and llvm#164798 have eliminated all calls to this, this patch removes the
function itself.
kcloudy0717 pushed a commit to kcloudy0717/llvm-project that referenced this pull request Dec 4, 2025
`tryDelinearizeFixedSizeImpl` is a heuristic function relying on GEP's
type information. Using these information to drive an optimization
heuristic is not allowed, so this function should be removed. As llvm#161822
and llvm#164798 have eliminated all calls to this, this patch removes the
function itself.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

llvm:analysis Includes value tracking, cost tables and constant folding

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants