Don't inline methods whose basic blocks end with a throw
If the basic block will end up throwing, it is commonly not in the
critical path. If we throw, we incur in a performance cost anyway
so we can skip inlining those methods. Additionally, methods
before a throw are sometimes construct information which is
something we are not interested in inlining.
Note that this CL doesn't stop inlining for methods that eventually
always end with a throw. See the 2243- test for an example
(testEndsWithThrowButNotDirectly). We could perform a more detailed
analysis but that analysis will increase compile time so it is left
as a further optimization if needed.
Locally in a Pixel 5 with AOSP, code size improved:
* AGSA: 15.3 MB (~4.6%)
* System Server: 1.9 MB (~3.74%)
* SysemUIGoogle: 0.88MB (~3.05%)
Bug: 252884414
Bug: 256052088
Bug: 255984757
Bug: 227283224
Test: art/test/testrunner/testrunner.py --host --64 --optimizing -b
Change-Id: Id0b7894c0d63591e3b354520a47252bf8b91f44f
diff --git a/compiler/optimizing/optimizing_compiler_stats.h b/compiler/optimizing/optimizing_compiler_stats.h
index 24a28e3..96dfdac 100644
--- a/compiler/optimizing/optimizing_compiler_stats.h
+++ b/compiler/optimizing/optimizing_compiler_stats.h
@@ -102,6 +102,7 @@
kNotInlinedNotCompilable,
kNotInlinedNotVerified,
kNotInlinedCodeItem,
+ kNotInlinedEndsWithThrow,
kNotInlinedWont,
kNotInlinedRecursiveBudget,
kNotInlinedPolymorphicRecursiveBudget,