[PATCH] D98213: [InlineCost] Enable the cost benefit analysis on FDO

[Kazu Hirata via Phabricator via llvm-commits]

kazu added a comment.

> Cycles are being compared against code size here. How is that metric supposed to be interpreted? What does (cycles/entry)/(bytes) even mean as a unit of measurement? The feature itself seems to be trying to optimize too fine details in machine cycles in a part of the compiler that shouldn't be dealing with such low level specifics.

If you would like to learn more about the cost-benefit analysis, there are a couple of papers:

- https://dl.acm.org/doi/10.1145/113446.113452
- https://dl.acm.org/doi/10.1145/351403.351416

The basic idea here is that if we are increasing the executable size by inlining a call site, that has to come with performance justification.  The quantity "cycle savings / size" allows us to rank call sites in the order of profitability.  We then inline those call sites exceeding a profitability threshold, namely `PSI->getOrCompHotCountThreshold() / InlineSavingsMultiplier`.  The papers above go one step further in that they the most inline profitable call site first by putting the ratio into a priority queue instead of traversing the call graph bottom up (as in LLVM).  I believe GCC inlines functions in a similar manner.

> Sorry I didn't see your comment at the time I was writing. Yes I see that now, it doesn't use absolute cycles. Ultimately the problem is that this heuristic basically overrides too much.
>
>   if (auto Result = costBenefitAnalysis()) {
>     DecidedByCostBenefit = true;
>     if (*Result)
>       return InlineResult::success();
>     else
>       return InlineResult::failure("Cost over threshold.");
>   }
>
> The `InlineResult::success()` being returned here effectively is `alwaysinline`. Even if we were to continue with this notion of cycle savings (which I don't think belongs in the inliner), a particularly bad inlining cost from the inliner can be completely overruled by this heuristic. Maybe we should only use this to inline the marginally bad cases (some max % of cost > threshold).

The cost-benefit analysis is intended to override the threshold-only heuristic.  That said, the traditional threshold in LLVM is compared against the cost, which is basically the callee size, and the cost-benefit analysis still takes size into account.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98213/new/

https://reviews.llvm.org/D98213