It seems that it is sometimes broken. Initial motivation for this was
investigation of https://github.com/llvm/llvm-project/issues/56260, but
it also seems that we have found an unrelated bug in LoopFusion that leaves
broken caches.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
13980 | Why does this not use the usual approach of comparing with the loop disposition on the other ScalarEvolution instance (SE2)? |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
13980 | I was hesitant about this because SE2 might also have wrong cache state (for same reasons). On other hand we might invalidate it all the time... Let's see if it works. |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
13980 | Ok, if we believe that only transform passes may break this, then it's fine. |
@mkazantsev Please can you take a look at the build failures on EXPENSIVE_CHECKS builds? https://lab.llvm.org/buildbot/#/builders/104/builds/9004
@RKSimon Should be fixed by https://github.com/llvm/llvm-project/commit/36f325413ec27819f8e4c1cd22d5f5e8a6a43000. Or maybe not fixed, but worked around :)
Why does this not use the usual approach of comparing with the loop disposition on the other ScalarEvolution instance (SE2)?