GDV: Multiple type-checks work items

[EgorBo]

A tracking issue for progress related to GDV with multiple type-checks. Essentially, today we expand virtual calls like this:

obj.DoWork(); // interface or virtual call and JIT doesn't know obj's exact type

Jit is able to record (probe) obj's type in Tier0 so then in Tier1 we can expand it like this;

if (obj is Class1)
    ((Class1)obj).DoWork(); // no longer virtual, can be inlined
else
    obj.DoWork(); // virtual call as a fallback

We call this Guarded Devirtualization or GDV.
However, for polymorphic virtual call-sites where we see more than a single dominating class we want to be able to expand multiple candidates, e.g.:

if (obj is Class1)
    ((Class1)obj).DoWork();
if (obj is Class2)
    ((Class2)obj).DoWork();
if (obj is Class3 || obj is Class4) // e.g. they share the same method since DoWork is not overriden in Class4
    ((Class3)obj).DoWork();
else
    obj.DoWork(); // fallback (can be omitted in case of NativeAOT)

Tasks:

• Clean up GenTreeCall's inline info #86540
• Chnage getLikelyClass to return multiple candidates: JIT: Return multiple likely classes in getLikelyClass (for better GDV) #58984
• Basic prototype: Guarded devirtualization: multiple type checks #86551 for NativeAOT
• Enable the basic prototype for Dynamic PGO + JIT (WIP: Devirtualization with multiple guesses: JIT #86809)
• Omit the virtual fallback in case of NativeAOT when we know all possible targets GDV: don't emit fallback call if classes are "exact" #87055
• Merge type checks if they target the same method - if (obj is Class3 || obj is Class4)
• Currently we only do GDV when candidates will be inlined, we should consider doing that for non-profitable-to-inline interface calls to (at least for NativeAOT) if it's beneficial
• Currently we give up on all candidates if some of them are not inlineable - we should either ignore them or just devirtualize like mentioned above ^ Multiple GDV: ignore non-inlineable candidates #86835
• Calculate optimal number of type checks (depending on their likelihoods)
• When we bake Static PGO into R2R we always embedd only the most popular candidate (single) - change that.
• Implement GDV chaining for cases when we have more than 1 candidate (GDV chaining is a feature where two subsequent virtual calls on top of the same object can share the type-check)
• Consider increasing reservoir's size for GDV candidates #86837
• Fix rounding error in getLikelyClassesOrMethods #86965
• Enable GDV with multiple guesses for NativeAOT #87380

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

A tracking issue for progress related to GDV with multiple type-checks. Essentially, today we expand virtual calls like this:

obj.DoWork();

is profiled and is expanded like this in Tier1:

if (obj is Class1)
    ((Class1)obj).DoWork(); // no longer virtual, can be inlined
else
    obj.DoWork(); // fallback

However, for virtual call-sites where we see more than a single dominating class we want to be able to expand multiple candidates, e.g.:

if (obj is Class1)
    ((Class1)obj).DoWork();
if (obj is Class2)
    ((Class2)obj).DoWork();
if (obj is Class3 || obj is Class4) // e.g. they share the same method
    ((Class3)obj).DoWork();
else
    obj.DoWork(); // fallback (can be omitted in case of NativeAOT)

Tasks:

• Basic prototype (WIP: Guarded devirtualization: multiple type checks #86551) for NativeAOT
• Enable the basic prototype for Dynamic PGO
• Omit the virtual fallback in case of NativeAOT when we know all possible targets Guarded devirtualization based on whole program view #86235
• Merge type checks if they target the same method
• Currently we only do GDV when candidates will be inlined, we should consider doing that for non-profitable-to-inline interface calls to (at least for NativeAOT) if it's beneficial
• Currently we give up on all candidates if some of them are not inlineable - we should either ignore them or just devirtualize like mentioned above ^
• Calculate optimal number of type checks (depending on their likelihoods)

Author:	EgorBo
Assignees:	-
Labels:	untriaged, area-NativeAOT-coreclr
Milestone:	-

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

A tracking issue for progress related to GDV with multiple type-checks. Essentially, today we expand virtual calls like this:

obj.DoWork(); // interface or virtual call and JIT doesn't know obj's exact type

Jit is able to record (probe) obj's type in Tier0 so then in Tier1 we can expand it like this;

if (obj is Class1)
    ((Class1)obj).DoWork(); // no longer virtual, can be inlined
else
    obj.DoWork(); // virtual call as a fallback

We call this Guarded Devirtualization or GDV.
However, for polymorphic virtual call-sites where we see more than a single dominating class we want to be able to expand multiple candidates, e.g.:

if (obj is Class1)
    ((Class1)obj).DoWork();
if (obj is Class2)
    ((Class2)obj).DoWork();
if (obj is Class3 || obj is Class4) // e.g. they share the same method since DoWork is not overriden in Class4
    ((Class3)obj).DoWork();
else
    obj.DoWork(); // fallback (can be omitted in case of NativeAOT)

Tasks:

• Basic prototype (WIP: Guarded devirtualization: multiple type checks #86551) for NativeAOT
• Enable the basic prototype for Dynamic PGO
• Omit the virtual fallback in case of NativeAOT when we know all possible targets Guarded devirtualization based on whole program view #86235
• Merge type checks if they target the same method - if (obj is Class3 || obj is Class4)
• Currently we only do GDV when candidates will be inlined, we should consider doing that for non-profitable-to-inline interface calls to (at least for NativeAOT) if it's beneficial
• Currently we give up on all candidates if some of them are not inlineable - we should either ignore them or just devirtualize like mentioned above ^
• Calculate optimal number of type checks (depending on their likelihoods)
• Implement GDV chaining for cases when we have more than 1 candidate (GDV chaining is a feature where two subsequent virtual calls on top of the same object can share the type-check)

Author:	EgorBo
Assignees:	EgorBo
Labels:	area-CodeGen-coreclr
Milestone:	Future