This will let the performance inliner inline a function even if the costs are too high.
This attribute is only a hint to the inliner.
If the inliner has other good reasons not to inline a function,
it will ignore this attribute. For example if it is a recursive function (which is
currently not supported by the inliner).
Note that setting the inline threshold to 0 does disable performance inlining at all and in
this case also the @inline(__always) has no effect.
Swift SVN r21452
PerfTests -----
Before
Totals,54,93821,93821,93821,0,0
Totals,54,86755,86755,86755,0,0
After
Totals,54,93610,93610,93610,0,0
Totals,54,85780,85780,85780,0,0
We may be able to tune BoostFactor for closure in PerformanceInliner.
Swift SVN r21312
If we have function A calls function B with a closure C
func A {
B(...) {
// closure C
}
}
and the inliner decides to not inline B into A, it may be beneficial to generate
a specialized version of B to have
func A {
B_spec_with_C(..., arguments_to_closure_C)
}
SILCombine will optimize apply of partial_apply that are both in B_spec_with_C.
Then inliner can inline the closure to B_spec_with_C.
For profitability, we check the relative size of the callee B and the closure C.
We also check hotness of the callsite to B in A and callsites to the closure
inside B. For now, if closure is called inside a loop, we think it is
profitable.
I will add this to the pass manager in a follow-up patch.
rdar://16569736
Swift SVN r21216
