bugpoint: make the number of trim iterations a compile-time constant

Around 10 year ago Chris limited this code to a single iteration by just
dropping a break into the loop body. We now make the number of trim iterations
a compile time constant to be able to play with it and see if this can
improve the bugpoint results. We currently use with '3' still a small and
conservative value, but this can be adjusted in the future, if needed.

I tried to look for a trivial test case, but did not succeed yet.

llvm-svn: 243247

1 files changed, 9 insertions, 3 deletions

diff --git a/llvm/tools/bugpoint/ListReducer.h b/llvm/tools/bugpoint/ListReducer.h
index a0bb570a5cb..f08bc97a998 100644
--- a/llvm/tools/bugpoint/ListReducer.h
+++ b/llvm/tools/bugpoint/ListReducer.h
@@ -75,6 +75,11 @@ struct ListReducer {
     // Maximal number of allowed splitting iterations,
     // before the elements are randomly shuffled.
     const unsigned MaxIterationsWithoutProgress = 3;
+
+    // Maximal number of allowed single-element trim iterations. We add a
+    // threshhold here as single-element reductions may otherwise take a
+    // very long time to complete.
+    const unsigned MaxTrimIterationsWithoutBackJump = 3;
     bool ShufflingEnabled = true;
 
 Backjump:
@@ -157,6 +162,7 @@ Backjump:
     if (TheList.size() > 2) {
       bool Changed = true;
       std::vector<ElTy> EmptyList;
+      unsigned TrimIterations = 0;
       while (Changed) {  // Trimming loop.
         Changed = false;
         
@@ -186,9 +192,9 @@ Backjump:
           if (!Error.empty())
             return true;
         }
-        // This can take a long time if left uncontrolled.  For now, don't
-        // iterate.
-        break;
+        if (TrimIterations >= MaxTrimIterationsWithoutBackJump)
+          break;
+        TrimIterations++;
       }
     }