PGO Inlining Policy

[AndyAyersMS]

Implement an inlining policy that takes PGO data more directly into account.

The general heuristic for an inline should be something like:

Cost = code size impact (may be negative)
Benefit = (global importance) * (local importance) * (per-call benefit)

Inline if:
   Cost <= 0                ;; inline is "free"
   Benefit/Cost > threshold ;; code size growth is justified by perf win

Global importance is somehow related to how often the root method is called. Perhaps non-linear, say 
  max(1, log10(#calls/10,000)) + 1

Local importance is the normalized execution count of the call site, that is
   call site count / method entry count

Per call benefit is related to the likelihood of callee specialization / caller benefit
   roughly how many cycles are saved per call by doing the inline

Suggest we start with the ModelPolicy which already has most of this structure, and amend/modify/clone it. Make the threshold adjustable and start to experiment.

We can use the size estimates that it produces as that seemed fairly accurate (in particular pretty good at predicting size-decreasing inlines).

Perhaps leave off global importance for now as we can't necessarily infer from TieredPGO how often a method is called, the value will depend in part on the rate of promotion to Tier1. So low method entry count may just mean the method got tiered up quickly (on the other hand, a high count does mean the method is called a lot).

[AndyAyersMS]

Prototyping on this branch.

[AndyAyersMS]

Preliminary version added in #44427. Still needs a fair bit of work.

[AndyAyersMS]

@EgorBo is going to work on inlining enhancements for PGO, so assigning this over to him.

[EgorBo]

I believe we can close it as we now take PGO data into account:
#52708
#53670
#55096
#55478

Or we can leave it open for future enhancements?

[AndyAyersMS]

Inlining is never done, but yes I think we can close this.