JIT: see if guarded devirtualization for EqualityComparer methods pays off

[AndyAyersMS]

The changes for devirtualizing the EqualityComparer<T>.Default calls (dotnet/coreclr#14125) don't kick in in cases where the user can optionally supply a custom comparer -- see for instance Dictionary<TKey, TValue> and many other generic collection types.

Since the jit can now determine the type of the default comparer, it might be worthwhile for the jit to insert a runtime test to see if a particular IEqualityComparer<T> typed object is actually the default comparer type for T, and if so, devirtualize and inline when the test succeeds.

I have a partial prototype of the changes needed here: master...AndyAyersMS:GuardedDevirtualization. This has most of the analysis needed to determine when the guarded devirtualization could be done cheaply enough that it is viable. However there are still some roadblocks to work out:

• Marking the IEqualityComparer<T> methods as [Intrinsic] leads to odd errors in the runtime when generating marshalling stubs. Not clear yet what is going on. For now the prototype just checks all interface calls for this interface type, which is likely going to slow the jit down considerably.
• The actual transformation can't be done in the current place(s) that impDevirtualizeCall is invoked, because the call may not yet be at top level. The rough idea here is to detect and defer this case, mark the original indirect call as an inline candidate, wait for it to get hoisted to top level, and then retry.

---

Update (Nov 2020): the guarded devirtualization transform is now available in the jit (see dotnet/coreclr#21270), but not enabled by default. We're still lacking the data needed to figure out which call sites would benefit, and at those sites, what class to guess for. PGO data can give us both of these.

Also note Dictionary<TKey, TValue> already contains explicit logic for accelerating the default equality comparer path (see dotnet/coreclr#15419), so opportunities for doing guarded devirtualization for objects with type IEqualityComparer<T> may not be as compelling. So a good first step here would be to find specific opportunities, likely classes like Dictionary where there's an optional user-overridable comparer supplied to the .ctor.

category:cq
theme:devirtualization
skill-level:expert
cost:medium

[AndyAyersMS]

Have some data that indicates that default comparers seem to predominate, so if we can speed them up a bit without slowing down the non-default comparers we may have something.

Considering this for 2.1.

[AndyAyersMS]

Probably not getting to this in time for 2.1, so moving it back to Future.

[AndyAyersMS]

GDV is now enabled whenever there is suitable PGO data, for any sort of virtual or interface call.

So, closing this.