-
Notifications
You must be signed in to change notification settings - Fork 14.4k
[DFAJumpThreading] Prevent pass from using too much memory. #145482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
The limit 'dfa-max-num-paths' that is used to control number of enumerated paths was not checked against inside getPathsFromStateDefMap. It may lead to large memory consumption for complex enough switch statements.
@llvm/pr-subscribers-llvm-transforms Author: Bushev Dmitry (dybv-sc) ChangesThe limit 'dfa-max-num-paths' that is used to control number of enumerated paths was not checked against inside getPathsFromStateDefMap. It may lead to large memory consumption for complex enough switch statements. Full diff: https://github.com/llvm/llvm-project/pull/145482.diff 1 Files Affected:
diff --git a/llvm/lib/Transforms/Scalar/DFAJumpThreading.cpp b/llvm/lib/Transforms/Scalar/DFAJumpThreading.cpp
index 938aab5879044..ac7af712bcf12 100644
--- a/llvm/lib/Transforms/Scalar/DFAJumpThreading.cpp
+++ b/llvm/lib/Transforms/Scalar/DFAJumpThreading.cpp
@@ -618,6 +618,8 @@ struct AllSwitchPaths {
VisitedBlocks UniqueBlocks;
for (auto *IncomingBB : Phi->blocks()) {
+ if(Res.size() >= MaxNumPaths)
+ break;
if (!UniqueBlocks.insert(IncomingBB).second)
continue;
if (!SwitchOuterLoop->contains(IncomingBB))
@@ -657,6 +659,8 @@ struct AllSwitchPaths {
getPathsFromStateDefMap(StateDef, IncomingPhi, VB);
for (ThreadingPath &Path : PredPaths) {
Path.push_back(PhiBB);
+ if(Res.size() >= MaxNumPaths)
+ break;
Res.push_back(std::move(Path));
}
continue;
@@ -679,6 +683,10 @@ struct AllSwitchPaths {
ThreadingPath NewPath(Path);
NewPath.appendExcludingFirst(IPath);
NewPath.push_back(PhiBB);
+ if(Res.size() >= MaxNumPaths) {
+ VB.erase(PhiBB);
+ return Res;
+ }
Res.push_back(NewPath);
}
}
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
Example of this pass using too much memory: Compilation of function |
@@ -679,6 +683,10 @@ struct AllSwitchPaths { | |||
ThreadingPath NewPath(Path); | |||
NewPath.appendExcludingFirst(IPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IntermediatePaths are appended to the list of PredPaths (here, and also in the run() function), so the total number of paths is the multiplication of the sizes of the two lists. IntermediatePaths are already calculated so we are wasting compute cycles here by doing wasteful computation and by breaking the loop later than we should.
Since getPathsFromStateDefMap()
and paths()
are called multiple times and from different places they don't see the global picture of the number of paths we already have.
My suggestion is to add an argument to these two functions and update every call to these functions with a more appropriate limit instead of MaxNumPaths
.
The limit 'dfa-max-num-paths' that is used to control number of enumerated paths was not checked against inside getPathsFromStateDefMap. It may lead to large memory consumption for complex enough switch statements.