[all-commits] [llvm/llvm-project] 29fa37: [SCEV] If max BTC is zero, then so is the exact BT...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 29fa37ec9fce16b6457fbd43c7a45f5e84b74d03
      https://github.com/llvm/llvm-project/commit/29fa37ec9fce16b6457fbd43c7a45f5e84b74d03
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2021-09-01 (Wed, 01 Sep 2021)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/lib/Target/ARM/MVETailPredication.cpp
    M llvm/test/Analysis/ScalarEvolution/max-trip-count.ll

  Log Message:
  -----------
  [SCEV] If max BTC is zero, then so is the exact BTC [2 of 2]

This extends D108921 into a generic rule applied to constructing ExitLimits along all paths. The remaining paths (primarily howFarToZero) don't have the same reasoning about UB sensitivity as the howManyLessThan ones did. Instead, the remain cause for max counts being more precise than exact counts is that we apply context sensitive loop guards on the max path, and not on the exact path. That choice is mildly suspect, but out of scope of this patch.

The MVETailPredication.cpp change deserves a bit of explanation. We were previously figuring out that two SCEVs happened to be equal because the happened to be identical. When we optimized one with context sensitive information, but not the other, we lost the ability to prove them equal. So, cover this case by subtracting and then applying loop guards again. Without this, we see changes in test/CodeGen/Thumb2/mve-blockplacement.ll

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