[all-commits] [llvm/llvm-project] e41dce: [LAA/LV] Simplify stride speculation logic [NFC] (...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e41dce4d4974f41d8e7572dfc698e5ddd55a3d4b
      https://github.com/llvm/llvm-project/commit/e41dce4d4974f41d8e7572dfc698e5ddd55a3d4b
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-05-11 (Thu, 11 May 2023)

  Changed paths:
    M llvm/include/llvm/Analysis/LoopAccessAnalysis.h
    M llvm/include/llvm/Analysis/VectorUtils.h
    M llvm/lib/Analysis/LoopAccessAnalysis.cpp
    M llvm/lib/Analysis/VectorUtils.cpp
    M llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
    M llvm/lib/Transforms/Vectorize/LoopVectorizationLegality.cpp

  Log Message:
  -----------
  [LAA/LV] Simplify stride speculation logic [NFC] (try 2)

The original commit wasn't quite NFC, and this was caught by an arguably overly strong assert.  Specifically, I'd failed to strip off the integer cast off the SCEV before saving it in the map.  The result - other than a failed assert - is that we'd speculate on the casted unknown, not the unknown.  The only case I can think of where that might change behavior would be a sext(i1 load).  I doubt that case is interesting in practice, but it's good to be strictly NFC on this change regardless.

Original commit message follows..

The existing code makes it hard to tell that collectStridedAccess is really about identifying some loop invariant SCEV which is *profitable* to speculate is equal to one. The odd dual usage structure of Value and SCEV confuses this point.

We could choose to loosen the profitability analysis if desired. I'm not proposing doing so at this time as it exposes too many cases where the speculation is unprofitable.

Differential Revision: https://reviews.llvm.org/D147750