[InlineCost] Reduce inline thresholds to compensate for cost changes
authorJames Molloy <james.molloy@arm.com>
Mon, 28 Nov 2016 11:07:37 +0000 (11:07 +0000)
committerJames Molloy <james.molloy@arm.com>
Mon, 28 Nov 2016 11:07:37 +0000 (11:07 +0000)
commit6bed13c5514df06979eb49e096a6dc69942c8edf
tree7347e502d4beed596089762c9f77c207037ef3a8
parent0c6efff178103f5b2bdeb6d20e5468027b02c13e
[InlineCost] Reduce inline thresholds to compensate for cost changes

In r286814, the algorithm for calculating inline costs changed. This
caused more inlining to take place which is especially apparent
in optsize and minsize modes.

As the cost calculation removed a skewed behaviour (we were inconsistent
about the cost of calls) it isn't possible to update the thresholds to
get exactly the same behaviour as before. However, this threshold change
accounts for the very common case where an inline candidate has no
calls within it. In this case, r286814 would inline around 5-6 more (IR)
instructions.

The changes to -Oz have been heavily benchmarked. The "obvious" value
for the inline threshold at -Oz is zero, but due to inaccuracies in the
inline heuristics this can actually cause code size increases due to
not inlining key thunk functions (that then disappear). Experimentally,
5 was the sweet spot for code size over the test-suite.

For -Os, this change removes the outlier results shown up by green dragon
(http://104.154.54.203/db_default/v4/nts/13248).

Fixes D26848.

llvm-svn: 288024
llvm/include/llvm/Analysis/InlineCost.h
llvm/test/Transforms/Inline/ephemeral.ll
llvm/test/Transforms/Inline/inline-fp.ll