Don't overly limit recursive inlining for monomorphic cases
After aosp/1978317 we are limiting the polmymorphic recursive inlining.
There are some cases in which we fall down the 'Polymorphic' case
even though we are monomorphic which we do not want to limit since
they are not responsible for code bloat.
Test: art/test/testrunner/testrunner.py --host --64 --optimizing -b
Test: Caffeine go/lem benchmark which regresses without this CL
Bug: 217464625
Change-Id: I000b24b4209b89911260efe8606490fb867198a7
diff --git a/compiler/optimizing/inliner.cc b/compiler/optimizing/inliner.cc
index 0157d65..8867792 100644
--- a/compiler/optimizing/inliner.cc
+++ b/compiler/optimizing/inliner.cc
@@ -958,7 +958,14 @@
dex::TypeIndex class_index = FindClassIndexIn(handle.Get(), caller_compilation_unit_);
HInstruction* return_replacement = nullptr;
+ // In monomorphic cases when UseOnlyPolymorphicInliningWithNoDeopt() is true, we call
+ // `TryInlinePolymorphicCall` even though we are monomorphic.
+ const bool actually_monomorphic = number_of_types == 1;
+ DCHECK(!actually_monomorphic || UseOnlyPolymorphicInliningWithNoDeopt());
+
+ // We only want to limit recursive polymorphic cases, not monomorphic ones.
const bool too_many_polymorphic_recursive_calls =
+ !actually_monomorphic &&
CountRecursiveCallsOf(method) > kMaximumNumberOfPolymorphicRecursiveCalls;
if (too_many_polymorphic_recursive_calls) {
LOG_FAIL(stats_, MethodCompilationStat::kNotInlinedPolymorphicRecursiveBudget)