[PATCH] D83160: [InstCombine] Lower infinite combine loop detection thresholds

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri created this revision.
lebedev.ri added reviewers: spatel, nikic, kuhar.
lebedev.ri added a project: LLVM.
Herald added a subscriber: hiraditya.

1000 iteratons is still kinda a lot.
Would it make sense to iteratively lower it, until it becomes `2`,
with some delay inbetween in order to let users actually potentially encounter it?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D83160

Files:
  llvm/lib/Transforms/InstCombine/InstructionCombining.cpp


Index: llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
===================================================================
--- llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
+++ llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
@@ -123,8 +123,9 @@
 DEBUG_COUNTER(VisitCounter, "instcombine-visit",
               "Controls which instructions are visited");
 
-static constexpr unsigned InstCombineDefaultMaxIterations = 1000;
-static constexpr unsigned InstCombineDefaultInfiniteLoopThreshold = 1000;
+// FIXME: these limits eventually should be as low as 2.
+static constexpr unsigned InstCombineDefaultMaxIterations = 100;
+static constexpr unsigned InstCombineDefaultInfiniteLoopThreshold = 100;
 
 static cl::opt<bool>
 EnableCodeSinking("instcombine-code-sinking", cl::desc("Enable code sinking"),


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D83160.275505.patch
Type: text/x-patch
Size: 829 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200704/8cd14989/attachment-0001.bin>