Inliner: new observations (don't impact inlining for now)

[EgorBo]

Extracted from #52708
Without changes which impact inlining decisions.

Empty jit diffs (as expected).

[EgorBo]

@dotnet/jit-contrib @AndyAyersMS Please, take a look.
These changes don't affect codegen, just preparations for #52708

[AndyAyersMS]

Some of the inline policies that derive from the DefaultPolicy should probably also implement the new per-policy xml dumping methods (invoking the parent version, then adding their own unique entries at the end).

Previously I'd dumped the data as a separate side file; keeping it inline with the xml makes sense. It feels like there might be cleaner ways to implement all this but I'm not sure it is worth the trouble. Better to focus on what we do with the data.

[EgorBo]

@AndyAyersMS could you please re-review?
NOTE: some observations aren't wired up in the PR, because in #52708 I had to re-write fgFindJumpTargets for them and I didn't want to do it in this PR.

Some of the inline policies that derive from the DefaultPolicy should probably also implement the new per-policy xml dumping methods (invoking the parent version, then adding their own unique entries at the end).
Previously I'd dumped the data as a separate side file; keeping it inline with the xml makes sense. It feels like there might be cleaner ways to implement all this but I'm not sure it is worth the trouble. Better to focus on what we do with the data.

Do you mind if I leave it as is for now, the per-policy XML stuff is not included by default if DOTNET_JitInlinePolicyDumpXml=1 is not set so it shouldn't affect any of your tools. It's just easier for me to validate effects of benefit multipliers on a collected data. Once I improve the DefaultPolicy I'll try to improve others, e.g. I'd love to re-calculate Model for ModelPolicy using these new observations.

I'm currently rewriting #52708 to be based on this PR

[AndyAyersMS]

Do you mind if I leave it as is for now, the per-policy XML stuff is not included by default

Sure, we can fix this later.

[EgorBo]

@AndyAyersMS could you please re-review, I've addressed your feedback.
Also, I checked that SuperPMI returns empty diffs as expected.

[AndyAyersMS]

Looks good overall. Let's just make sure we get the right check for generic methods.

[EgorBo]

A test for generics:

using System;

class Program
{
    static void Main()
    {
        Console.WriteLine(GenericClass<string>.Case1(1));
        Console.WriteLine(GenericClass<string>.Case2(1));
        Console.WriteLine(GenericClass<long>.Case1(1));
        Console.WriteLine(GenericClass<long>.Case2(1));
        Console.WriteLine(NonGenericClass.Case3<int>(1));
        Console.WriteLine(NonGenericClass.Case3<string>(""));
    }
}

public class GenericClass<T>
{

    // Case1: class is a [shared] generic, method doesn't use T
    public static int Case1(int a)
    {
        if (a == 42)
            throw new Exception("hello"); // some random code to exceed ALWAYS_INLINE limit
        return 0;
    }

    // Case2: class is a [shared] generic, method uses T
    public static int Case2(int a)
    {
        if (typeof(T) == typeof(float))
            throw new Exception("hello"); // some random code to exceed ALWAYS_INLINE limit
        return 0;
    }
}

public class NonGenericClass
{
    // Case3: class is not generic, method is
    public static int Case3<T>(T a)
    {
        if (a is float)
            throw new Exception("hello"); // some random code to exceed ALWAYS_INLINE limit
        return 0;
    }
}

[AndyAyersMS]

I still think the interesting case is when caller is not shared (generic or no) and callee is shared, but let's see how this plays out when you add heuristics based on these observations.

[EgorBo]

I still think the interesting case is when caller is not shared (generic or no) and callee is shared, but let's see how this plays out when you add heuristics based on these observations.

Will check that case separately too