Implement initThisClass for generic types in ReadyToRun (dotnet/coreclr#7842)

Only implementing the RyuJIT portion for CoreRT purposes (CoreRT side at dotnet/corertdotnet/coreclr#2085).
I can file an issue to add support for this in CoreCLR if there's interest. On CoreCLR this is currently a disqualification from ReadyToRun and causes fallback to JITting.

Commit migrated from https://github.com/dotnet/coreclr/commit/96d7b6fa7ed6c2568b41c6bab32efef012a0b32f

diff --git a/src/coreclr/src/jit/morph.cpp b/src/coreclr/src/jit/morph.cpp
index 32915be..67249fd 100644 (file)
--- a/src/coreclr/src/jit/morph.cpp
+++ b/src/coreclr/src/jit/morph.cpp
@@ -16209,6 +16209,23 @@ GenTreePtr Compiler::fgInitThisClass()
     }
     else
     {
+#ifdef FEATURE_READYTORUN_COMPILER
+        // Only CoreRT understands CORINFO_HELP_READYTORUN_GENERIC_STATIC_BASE. Don't do this on CoreCLR.
+        if (opts.IsReadyToRun() && eeGetEEInfo()->targetAbi == CORINFO_CORERT_ABI)
+        {
+            CORINFO_RESOLVED_TOKEN resolvedToken;
+            ZeroMemory(&resolvedToken, sizeof(resolvedToken));
+
+            GenTreePtr ctxTree = getRuntimeContextTree(kind.runtimeLookupKind);
+
+            // CORINFO_HELP_READYTORUN_GENERIC_STATIC_BASE with a zeroed out resolvedToken means "get the static
+            // base of the class that owns the method being compiled". If we're in this method, it means we're not
+            // inlining and there's no ambiguity.
+            return impReadyToRunHelperToTree(&resolvedToken, CORINFO_HELP_READYTORUN_GENERIC_STATIC_BASE, TYP_BYREF,
+                                             gtNewArgList(ctxTree), &kind);
+        }
+#endif
+
         // Collectible types requires that for shared generic code, if we use the generic context paramter
         // that we report it. (This is a conservative approach, we could detect some cases particularly when the
         // context parameter is this that we don't need the eager reporting logic.)