Limit recursive polymorphic inlining to prevent code bloat

If both NoRecursion and Wrapper implement the same method
MyMethod, NoRecursion with just `return false` and Wrapper
with `return BaseClass.MyMethod()` we would end up with
generated code similar to:

```
if (receiver == NoRecursion) {
  return false;
} else if (receiver == Wrapper) {
  // A polymorphic invoke which turns into:
  if (unwrappedValue.receiver == NoRecursion) {
    return false;
  } else if (unwrappedValue.receiver == Wrapper) {
    // A polymorphic invoke which turns into
    // [...] you get the gist, we do this several times.
  } else {
    // HInvokeVirtual
  }
} else {
  // HInvokeVirtual
}
```

After the change we would have:
```
if (receiver == NoRecursion) {
  return false;
} else {
  // HInvokeVirtual
}
```

This pattern was worse when there were more than one recursive
polymorphic case, increasing exponentially in size. This was
common to see on Wrapper classes, but uncommon otherwise.

In the two wrappers plus one non-wrapper case in test/2238-,
we will now generate a .cfg which is about 6% the size versus
before this CL (12M -> 779K).

Test: art/test/testrunner/testrunner.py --host --64 --optimizing -b
Bug: 217464625
Change-Id: I3c6444193ea2f24af29d97549776a283ef177efd

1 files changed, 1 insertions, 0 deletions

diff --git a/compiler/optimizing/optimizing_compiler_stats.h b/compiler/optimizing/optimizing_compiler_stats.h
index a68a0be393..d458e42608 100644
--- a/compiler/optimizing/optimizing_compiler_stats.h
+++ b/compiler/optimizing/optimizing_compiler_stats.h
@@ -100,6 +100,7 @@ enum class MethodCompilationStat {
   kNotInlinedCodeItem,
   kNotInlinedWont,
   kNotInlinedRecursiveBudget,
+  kNotInlinedPolymorphicRecursiveBudget,
   kNotInlinedProxy,
   kNotInlinedUnresolved,
   kNotInlinedPolymorphic,