Simplify devirtualization in crossgen2

[jkotas]

No description provided.

[jkotas]

@MichalStrehovsky suggested in dotnet/runtimelab#437 (comment) that the call to FindMethodOnTypeWithMatchingTypicalMethod may not be required.

@AndyAyersMS Do you happen to remember why you have added it?

[AndyAyersMS]

As part of #45526 I asked David what the counterpart was to GetExactDeclaringType in the runtime, and this is what he suggested.

[jkotas]

The managed type system is always exact. It does not share MethodDesc between types some of the time like the CoreCLR runtime type system that requires the GetExactDeclaringType.

I believe that it should be safe to delete this as proposed in this PR.

[AndyAyersMS]

Is there a writeup anywhere on how the managed type system differs from the type system in the runtime?

[jkotas]

We have write up at https://github.com/dotnet/corert/blob/master/Documentation/botr/type-system.md

The doc does not have an explicit list. Most of the differences fall out from the design. This specific detail is fall out from the pluggable algorithms.

In CoreCLR type system, MethodDescs have to have 1:1 mapping with entrypoints. It means that the code sharing policy affects when you get exact MethodDescs.

In managed type system, the code sharing policy is one of the pluggable algorithms and it does not have cascading affect on how the type system as a whole works.

[AndyAyersMS]

Thanks. I would not have deduced that a pluggable sharing policy implies that there are only exact types.

Given that we're going to support both type systems indefinitely, perhaps it is worth being more explicit on how things differ between the two?

[MichalStrehovsky]

Thanks!

[jkotas]

perhaps it is worth being more explicit on how things differ between the two?

dotnet/runtimelab#440. Also, I will look into moving this doc to dotnet/runtime.