Inliner: initial data gathering for code size estimates
Some initial work to gather data to drive the modelling of inline
code size impact. See dotnet/coreclr#3775 for context.
Update the `DiscretionaryPolicy` to capture more observations.
Add a limit feature `JitInlineLimit` so the jit will stop inlining after
a given number of successful inlines.
Add a `DumpData` method to `InlinePolicy` which will display all the
observations that were made to evaluate an inline. Implement this for the
`DiscretionaryPolicy`. Add a matching `DumpSchema` that writes out
column headers for each of the observations.
Modify `InlineResult` to cache the last successful policy on the root
compiler instance. Use that along with the `JitInlineLimit` and
`DumpData` to display detailed information about the last sucessful
inline along with the code size for the method. All this is displayed
if `JitInlineDumpData ` is enabled.
This allows for isolating code size measurements as follows. Compile or
jit something with `JitInlineLimit = 0` and `JitInlineDumpData =1` (and
for now, `JitInlinePolicyDiscretionary = 1`, since other policies do not
implement any interesting data dumping).
Record the this root set of method sizes and IDs. Repeat with
`JitInlineLimit=1`. For each method where there was an inline, the size
impact of that inline can be computed by comparing this version versus
the version from the root set. Repeat with `JitInlineLimit=2`, comparing
versus the `=1` versions.
Currently the method token is used to identify the root method. This is
not sufficiently unique but unfortunately there currently aren't
substantially better alternatives. See dotnet/coreclr#1957 for some discussion.
Commit migrated from https://github.com/dotnet/coreclr/commit/
5c7dd45d7c035445a33a321c595a03fba73da93f