[llvm-bugs] [Bug 43545] New: [ScalarEvolution] Seems to have un-updated data structures.

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43545

            Bug ID: 43545
           Summary: [ScalarEvolution]  Seems to have un-updated data
                    structures.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: paulsson at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 22625
  --> https://bugs.llvm.org/attachment.cgi?id=22625&action=edit
reduced testcase

During recent experiments involving SCEV (https://reviews.llvm.org/D68281), I
found that the SCEV "cache" seems to not always reflect the current IR as I was
expecting.

In fact, when adding this:

diff --git a/lib/Transforms/Scalar/LoopStrengthReduce.cpp
b/lib/Transforms/Scalar/LoopStrengthReduce.cpp
index 852bbef..7d188ad 100644
--- a/lib/Transforms/Scalar/LoopStrengthReduce.cpp
+++ b/lib/Transforms/Scalar/LoopStrengthReduce.cpp
@@ -5737,6 +5737,7 @@ bool LoopStrengthReduce::runOnLoop(Loop *L, LPPassManager
& /*LPM*/) {

   auto &IU = getAnalysis<IVUsersWrapperPass>().getIU();
   auto &SE = getAnalysis<ScalarEvolutionWrapperPass>().getSE();
+  SE.forgetAllLoops();
   auto &DT = getAnalysis<DominatorTreeWrapperPass>().getDomTree();
   auto &LI = getAnalysis<LoopInfoWrapperPass>().getLoopInfo();
   const auto &TTI = getAnalysis<TargetTransformInfoWrapperPass>().getTTI(

, I see a lot of files changing in benchmarks.

It says that recomputation can be "potentially expensive for large loop
bodies." in ScalarEvolution.h. I wonder if there has been some decisions to
allow a very small amount of differences to reduce compile time? Would it be
possible to find the places to update the right SCEVs instead of accepting
output differences? Having these differences in output makes it harder to work
with other passes since then unrelated changes to a pass affect code generation
in unpredictible ways.

The attached reduced test case has on trunk three phi instructions after LSR,
but with the above LSR patch to forgetAllLoops(), it has only two...

llc -mtriple=s390x-linux-gnu -mcpu=z14 -o - -O3 ./tc_lsr_scev.ll
-stop-after=loop-reduce

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191003/b93ed92e/attachment-0001.html>