JIT: Convert some of the old-style intrinsics to NamedIntrinsics

[EgorBo]

It's needed for inliner that handles only NamedIntrinsics. Eventually, I guess, we'll get rid of all of the old-style ones.

[EgorBo]

@dotnet/jit-contrib PTAL

[EgorBo]

@dotnet/jit-contrib @echesakovMSFT PING 🙂 I'd love to merge it and unblock my next inliner-related PR on top of it

[echesakov]

Sorry for keep you waiting..
Overall, looks good - left some comments.

BTW, have you encountered any diffs with this change?

[AndyAyersMS]

Let me echo what @echesakov wrote above: you really need to show that this doesn't lead to diffs. Given the the changes in the jit interface you can't use SPMI -- you should use jit diffs in both PMI and Crossgen2 modes for this, running base and diff separately (since the jits can't be swapped), over all the frameworks assemblies.

[EgorBo]

@AndyAyersMS @echesakovMSFT thanks for review, unfortunately I caught a small regression in crossgen (and crossgen2) so I decided to temporarily leave Object.GetType to be old-style.
Now there are zero size regressions in PMI, crossgen and crossgen2 for corelib and framework libs.

[EgorBo]

So does anybody mind if I merge it (it contains JIT-EE id update)? It's approved and has zero regression across JIT, crossgen and crossgen2

[AndyAyersMS]

Can you say a bit more about the problems you had with converting Object.GetType and why you ultimately decided you could live without it...perhaps in an issue you open to track converting it to new style?

[EgorBo]

Can you say a bit more about the problems you had with converting Object.GetType and why you ultimately decided you could live without it...perhaps in an issue you open to track converting it to new style?

I didn't give up, just wanted to do it iteratively for all of them eventually to keep the PRs easier to review.

The primary goal is the ability to recognize typeof(T) cmp typeof(T) in inliner (and String.Length), from my understanding - foldable obj.GetType() == typeof() patterns where obj's type is known/final are less common (but I might be wrong).

Object.GetType led to this assert: https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/importer.cpp#L8185

eeCallInfo returned CORINFO_VIRTUALCALL_STUB for it instead. I suspect the problem is here: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs#L1587-L1589 (and a similar code in the native crossgen1)

Both crossgens know nothing about the new style intrinsics, I tried to fix this specific case like this 65a9154 and looked like it helped but none-windows platforms still asserted so I decided to postpone it a bit 🙁

[EgorBo]

@AndyAyersMS so, do you want me to have a look at Object.GetType again as part of this PR or we can have it as is? (I just want to unblock my next PR for inliner)

CI Failures are not related (#52596)

[AndyAyersMS]

It can be separate. Open an issue and record the details and link it to this PR.

[EgorBo]

It can be separate. Open an issue and record the details and link it to this PR.

Done: #52620

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).