[PATCH] D123400: [LoopCacheAnalysis] Consider dimension depth of the subscript reference when calculating cost

[Bardia Mahjour via Phabricator via llvm-commits]

bmahjour added a comment.

> What I did is to take the stride into account as a second component, and for each loop take the maximum stride of all reference groups to get the final stride, which presumably could resolve the motivating problem too.

Treating stride as a secondary component is what I respectfully objected to, and explained earlier. Not sure if taking the maximum stride would give us what we need. For example consider

  for (i)
    for (j)
      for (k)
         ... A[i][j][k]
         ... B[i][k][j]
         ... C[i][k][j]

the maximum stride will be the same for both `i-j-k` and `i-k-j` configurations (despite the second one being more profitable) bringing us back to the original problem.

> After you land this patch, I hope that I could get the test case in D122776 <https://reviews.llvm.org/D122776> merged, since that is really the motivating test for these works. I could update the "CHECK: " lines according to the approach proposed in this patch, and update D122776 <https://reviews.llvm.org/D122776> to a pure NFC patch which includes only that test. I look forward to your thoughts about it :)

Isn't `llvm/test/Analysis/LoopCacheAnalysis/PowerPC/single-store.ll` providing the same test coverage? Note that the analysis is not sensitive to the order of the loops within the loop nest, as it considers all permutations regardless of the original order.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123400/new/

https://reviews.llvm.org/D123400