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:

usingSystem;classProgram{staticvoidMain(){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>(""));}}publicclassGenericClass<T>{// Case1: class is a [shared] generic, method doesn't use TpublicstaticintCase1(inta){if(a==42)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}// Case2: class is a [shared] generic, method uses TpublicstaticintCase2(inta){if(typeof(T)==typeof(float))thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}publicclassNonGenericClass{// Case3: class is not generic, method ispublicstaticintCase3<T>(Ta){if(aisfloat)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}

[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

[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:

usingSystem;classProgram{staticvoidMain(){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>(""));}}publicclassGenericClass<T>{// Case1: class is a [shared] generic, method doesn't use TpublicstaticintCase1(inta){if(a==42)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}// Case2: class is a [shared] generic, method uses TpublicstaticintCase2(inta){if(typeof(T)==typeof(float))thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}publicclassNonGenericClass{// Case3: class is not generic, method ispublicstaticintCase3<T>(Ta){if(aisfloat)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}

[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

[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:

usingSystem;classProgram{staticvoidMain(){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>(""));}}publicclassGenericClass<T>{// Case1: class is a [shared] generic, method doesn't use TpublicstaticintCase1(inta){if(a==42)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}// Case2: class is a [shared] generic, method uses TpublicstaticintCase2(inta){if(typeof(T)==typeof(float))thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}publicclassNonGenericClass{// Case3: class is not generic, method ispublicstaticintCase3<T>(Ta){if(aisfloat)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}

[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

[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:

usingSystem;classProgram{staticvoidMain(){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>(""));}}publicclassGenericClass<T>{// Case1: class is a [shared] generic, method doesn't use TpublicstaticintCase1(inta){if(a==42)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}// Case2: class is a [shared] generic, method uses TpublicstaticintCase2(inta){if(typeof(T)==typeof(float))thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}publicclassNonGenericClass{// Case3: class is not generic, method ispublicstaticintCase3<T>(Ta){if(aisfloat)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}

[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

[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:

usingSystem;classProgram{staticvoidMain(){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>(""));}}publicclassGenericClass<T>{// Case1: class is a [shared] generic, method doesn't use TpublicstaticintCase1(inta){if(a==42)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}// Case2: class is a [shared] generic, method uses TpublicstaticintCase2(inta){if(typeof(T)==typeof(float))thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}publicclassNonGenericClass{// Case3: class is not generic, method ispublicstaticintCase3<T>(Ta){if(aisfloat)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}

[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

[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:

usingSystem;classProgram{staticvoidMain(){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>(""));}}publicclassGenericClass<T>{// Case1: class is a [shared] generic, method doesn't use TpublicstaticintCase1(inta){if(a==42)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}// Case2: class is a [shared] generic, method uses TpublicstaticintCase2(inta){if(typeof(T)==typeof(float))thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}publicclassNonGenericClass{// Case3: class is not generic, method ispublicstaticintCase3<T>(Ta){if(aisfloat)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}

[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

[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:

usingSystem;classProgram{staticvoidMain(){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>(""));}}publicclassGenericClass<T>{// Case1: class is a [shared] generic, method doesn't use TpublicstaticintCase1(inta){if(a==42)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}// Case2: class is a [shared] generic, method uses TpublicstaticintCase2(inta){if(typeof(T)==typeof(float))thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}publicclassNonGenericClass{// Case3: class is not generic, method ispublicstaticintCase3<T>(Ta){if(aisfloat)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}

[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

[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:

usingSystem;classProgram{staticvoidMain(){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>(""));}}publicclassGenericClass<T>{// Case1: class is a [shared] generic, method doesn't use TpublicstaticintCase1(inta){if(a==42)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}// Case2: class is a [shared] generic, method uses TpublicstaticintCase2(inta){if(typeof(T)==typeof(float))thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}publicclassNonGenericClass{// Case3: class is not generic, method ispublicstaticintCase3<T>(Ta){if(aisfloat)thrownewException("hello");// some random code to exceed ALWAYS_INLINE limitreturn0;}}

[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