This converts LoopFlatten from a LoopPass to a FunctionPass so that we don't run into problems of a loop pass deleting a (inner)loop.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/include/llvm/Transforms/Scalar.h | ||
---|---|---|
340 | Is there an important ordering to this file? It's not alphabetical.. Any reason why it's moved? | |
llvm/lib/Transforms/Scalar/LoopFlatten.cpp | ||
536 | Should this be handling sub-loops too? Maybe use getLoopsInPreorder if that works how I think it does? | |
574 | Does this preserve all the things a loop pass would? I think the answer is yes, but it's perhaps worth checking. LI seems to be kept up to date, which was the one I was worried about. |
llvm/include/llvm/Transforms/Scalar.h | ||
---|---|---|
340 | Thanks for looking at this Dave. I thought of clustering it with the other FunctionPasses, but now I see that's not really true (it's mixed already), so will move it back. | |
llvm/lib/Transforms/Scalar/LoopFlatten.cpp | ||
536 | Ah, I guess so. This will flatten only doubly nested loops, but won't flatten j and k in a 3d loop: for i for j for k Looks like a test is missing too... | |
574 | Will double check. |
llvm/lib/Transforms/Scalar/LoopFlatten.cpp | ||
---|---|---|
536 | But maybe this is not supported anyway, will check. |
llvm/test/Transforms/LoopFlatten/loop-flatten-negative.ll | ||
---|---|---|
404 | None of these are flattened? Any idea why? You can remove dso_local and local_unnamed_addr #0 |
llvm/test/Transforms/LoopFlatten/loop-flatten-negative.ll | ||
---|---|---|
404 |
Yeah, looks like there's room for improvement. They are rejected for different reasons:
|
llvm/lib/Transforms/Scalar/LoopFlatten.cpp | ||
---|---|---|
558 | CFG is changed. Does this pass update CFGAnalyses on its own? If not, I believe this line should be removed. |
Is there an important ordering to this file? It's not alphabetical..
Any reason why it's moved?