[all-commits] [llvm/llvm-project] 9c1d5e: [SCEV][reland] More precise trip multiples

[Joshua Cao via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9c1d5e4ae3498d22287c6f36f7f029bab6cd5d81
      https://github.com/llvm/llvm-project/commit/9c1d5e4ae3498d22287c6f36f7f029bab6cd5d81
  Author: Joshua Cao <cao.joshua at yahoo.com>
  Date:   2023-05-07 (Sun, 07 May 2023)

  Changed paths:
    M llvm/include/llvm/Analysis/ScalarEvolution.h
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/test/Analysis/ScalarEvolution/nsw.ll
    M llvm/test/Analysis/ScalarEvolution/ranges.ll
    M llvm/test/Analysis/ScalarEvolution/trip-multiple-guard-info.ll
    M llvm/test/Analysis/ScalarEvolution/trip-multiple.ll

  Log Message:
  -----------
  [SCEV][reland] More precise trip multiples

We currently have getMinTrailingZeros(), from which we can get a SCEV's
multiple by computing 1 << MinTrailingZeroes. However, this only gets us
multiples that are a power of 2. This patch introduces a way to get max
constant multiples that are not just a power of 2. The logic is similar
to that of getMinTrailingZeros. getMinTrailingZerosImpl is replaced by
computing the max constant multiple, and counting the number of trailing
bits.

I have so far found this useful in two places:

1) Computing unsigned constant ranges. For example, if we have i8
   {10,+,10}<nuw>, we know the max constant it can be is 250.

2) My original intent was to use this in getSmallConstantTripMultiples,
   but it has no effect right now due to change from D110587. For
   example, if we have backedge count `(6 * %N) - 1`, the trip count
   becomes `1 + zext((6 * %N) - 1)`, and we cannot say that 6 is a
   multiple of the SCEV. I plan to look further into this separately.

The implementation assumes the value is unsigned. It can probably be
extended to handle signed values as well.

If the code sees that a SCEV does not have <nuw>, it will fall back to
finding the max multiple that is a power of 2. Multiples that are a
power of 2 will still be a multiple even after the SCEV overflows. This
does not apply to other values. This is the 1st commit message:

---

This relands https://reviews.llvm.org/D141823. The verification fails
when expensive checks are turned on. This can occur when:

1. SCEV S's multiple is cached
2. SCEV S's no wrap flags are strengthened, and the multiple changes
3. SCEV verifier finds that S's cached and recomputed multiple are
   different

We eliminate most cases by forgetting SCEVAddRecExpr's cached values
when the flags are modified, but there are still cases for other SCEV
types. We relax the check by making sure the cached multiple divides the
recomputed multiple, ensuring the cached multiple is correct,
conservative multiple.

Reviewed By: mkazantsev

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