diff options
| author | Philip Reames <listmail@philipreames.com> | 2021-09-01 11:33:15 -0700 |
|---|---|---|
| committer | Philip Reames <listmail@philipreames.com> | 2021-09-01 11:51:48 -0700 |
| commit | 29fa37ec9fce16b6457fbd43c7a45f5e84b74d03 (patch) | |
| tree | 0a575b92fccb7cc32f2bb92a7cf4e3d0fa67021d /clang/unittests/Basic/FileManagerTest.cpp | |
| parent | 3d157cfcc4ef2b4e09a36d3249c960d0a4099ca7 (diff) | |
| download | llvm-29fa37ec9fce16b6457fbd43c7a45f5e84b74d03.zip llvm-29fa37ec9fce16b6457fbd43c7a45f5e84b74d03.tar.gz llvm-29fa37ec9fce16b6457fbd43c7a45f5e84b74d03.tar.bz2 | |
[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
Diffstat (limited to 'clang/unittests/Basic/FileManagerTest.cpp')
0 files changed, 0 insertions, 0 deletions