LoopRotate only invalidates innermost loops while the changes that it makes may
also affert any of this parents. With patch rL329047, SCEV becomes much smarter
about calculation of exit counts for outer loops, so we cannot assume that they are
not affected.
Details
Diff Detail
Event Timeline
So generally, as a matter of politeness, good to avoid the review if you're gonna go with post-submit.
However I also have a question here -- are we going to have any SCEV left?
We don't re-run SCEV mid-way through the loop pass manager. If we invalidate all outer scevs when we loop rotate, won't that completely defeat SCEVs analysis on outer loops? Or will we lazily rebuild it?
We will lazily rebuild SCEV expressions as needed. Not great for compile time, but we should be functionally correct.
@mkazantsev: IMO this illustrates an architectural problem with SCEV's cache -- ideally the cache would parallel the hierarchy of the loop tree itself so that changing an inner loop does not require us to throw away all of the information computed on the outer loop. Do you have some ideas on how we can fix this architectural issue?
llvm/trunk/lib/Transforms/Utils/LoopRotationUtils.cpp | ||
---|---|---|
262 ↗ | (On Diff #143529) | Can you please add a comment on *how* we can affect parent loops? Rotating an inner loop should not change the trip count of outer loops so right now the statement sounds a bit confusing. Perhaps: "Loop rotation can change the dominance relationships between blocks in the inner loop and blocks in the outer loop. It may also delete blocks from the inner loop. Both of these may end up violating invariants in backedge taken infos cached by SCEV about outer loops." |
llvm/trunk/lib/Transforms/Utils/LoopRotationUtils.cpp | ||
---|---|---|
262 ↗ | (On Diff #143529) |