[PATCH] D50704: [Inline-cost] Teach cost function to account for accumulative code-size growth

[David Greene via Phabricator via llvm-commits]

greened added inline comments.


================
Comment at: lib/Analysis/InlineCost.cpp:1913
+
+  int Growth = (NumInstructions - NumInstructionsSimplified) * F.getNumUses();
+
----------------
eraman wrote:
> dnsampaio wrote:
> > greened wrote:
> > > 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.
> > 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.
> > 
> The cost of a callee depends on the callsite so multiplying the cost for one callsite by number of uses is not very meaningful. 
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.


https://reviews.llvm.org/D50704