To make the IR easier to analyze, this pass makes some minor transformations.
After that, even if it doesn't decide to optimize anything, it can't report that
it changed nothing and preserved all the analyses.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM.
Your code is correct and fixes a real potential issue, but your test may not be the best one. From what I can tell, the changes being missed were strictly mutations/moves of instructions, not manipulations of the CFG. As a result, the CFG analysis you're testing being invalidated could actually be preserved with a bit of extra work.
I agree with that, that's why left a note about it in the test in case someone breaks the test by making the pass preserve this analysis:
; NOTE: PreservedCFGCheckerAnalysis is an arbitrary analysis that just happens ; to be calculated before this pass and isn't preserved by it.
To fix the test that person will need to find some other analysis that isn't preserved. Maybe it makes sense to add that to the note.
But, I think, the same can be said about basically any analysis: with some extra effort you can preserve all of them. The best solution would be to introduce some debug print that says either "this pass didn't preserve all analyses" or "this pass preserved everything", but I think at the moment just having a note in the test is somewhat adequate.
llvm/lib/Transforms/Scalar/LoopPredication.cpp | ||
---|---|---|
1129 | Why don't we invalidate SCEV cache after it? I think it's a bug. |
llvm/lib/Transforms/Scalar/LoopPredication.cpp | ||
---|---|---|
1129 | It's good you noticed it! Though I can't say for sure why it's a bug and if it's a bug at all, I don't know SCEV as good as you do. Maybe you happen to have a testcase that would demonstrate that SCEV is in invalid state after this transformation? Anyway, given your knowledge of SCEV and this pass, you seem to be way better equipped for proving that this is a bug and fixing it, so maybe you can handle it? Just to clarify: the problem of a missed SCEV update doesn't seem directly related to the problem of "this pass incorrectly reports that it preserved everything", so I hope you're not implying that this patch must have fixed this problem too. |
Why don't we invalidate SCEV cache after it? I think it's a bug.