The current Inline-cost function does not take into account the accumulative code size growth of inlining calls to the same function multiple times.
If N function calls to a function are inlined, each increasing size by I, the accumulative code growth is N * I.
If the callee has local linkage, then we give it a bonus, as the function can be eliminated by the number of instruction in the function.
Details
- Reviewers
chandlerc greened SjoerdMeijer
Diff Detail
Event Timeline
test/Transforms/Inline/InlineGrowthCost.ll | ||
---|---|---|
2–3 | Can't you just use FileCheck? |
lib/Analysis/InlineCost.cpp | ||
---|---|---|
1908 | S - (N*X) doesn't match what the comment message says and doesn't make sense to me in this context. If N is large enough, this says the growth could become negative. | |
1913 | This assumes all uses are inlined. That seems overly pessimistic. I'm not sure it's wise to predict what the inliner will do in the cost model. It seems like an incremental cost would be better. The inliner would then do the cost analysis for each inlining opportunity and decide on a case-by-case basis whether to inline or not. As written, this seems to have the cost model driving inline decisions (inline everything or nothing) rather than the inliner using cost information to make decisions. |
lib/Analysis/InlineCost.cpp | ||
---|---|---|
1908 | Indeed the comment wrong. It should be (N*X). Will fix it. The stipulated growth is N * (NumberOfInstrucions - NumberOfSimplifiedInstructions), where the last is expected, due the previous analysis. Yes, it is a pessimistic assumption, but with such a small threshold, is quite effective. If the function has local linkage, then the expected growth might be negative, as the function will be eliminated, and the cost would actually be (N*X)-S. | |
1913 | The cost-function analysis using -Oz are not that complex. It only considers each of the instructions (if they can be simplified if inlined), arguments passed and a constant cost for the call site. And see that it is incremental already. The additional cost decreases each time the function is inlined, that is, N reduces. The first one has the higher penalty, the last ones the higher benefit. Not counting the last one that gains huge bonus already. |
lib/Analysis/InlineCost.cpp | ||
---|---|---|
286 | Turning on ComputeFullInlineCost can lead to excessive compile time for pathological cases. It changes the cost to analyze a function F from O(1) [the constant here depends on inline threshold] to O(size of F) and will particularly be bad for Oz because the threshold is low to start with. | |
1913 | The cost of a callee depends on the callsite so multiplying the cost for one callsite by number of uses is not very meaningful. |
lib/Analysis/InlineCost.cpp | ||
---|---|---|
1913 | It seems weird to have the cost decrease as inlining is done. I understand that's what happens given the current formulation, but I'm not sure the current formulation is correct. The cost of a single inline operation isn't N*X but rather X. By calculating the cost as N*X the code is assuming all calls to the function are inlined. |
Turning on ComputeFullInlineCost can lead to excessive compile time for pathological cases. It changes the cost to analyze a function F from O(1) [the constant here depends on inline threshold] to O(size of F) and will particularly be bad for Oz because the threshold is low to start with.