Delete VersionsWithType check from embedClassHandle

[jkotas]

It should not be needed. Also, embedClassHandle alternative in embedGenericHandle does not have this check.

[Copilot]

Pull Request Overview

This PR removes the unnecessary VersionsWithType check and associated exception from embedClassHandle to align its behavior with embedGenericHandle.

• Deleted the guard that threw RequiresRuntimeJitException when a type wasn’t in VersionsWithType
• Streamlined embedClassHandle to always emit a ready-to-run helper for the type handle

Comments suppressed due to low confidence (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs:2739

• With the removal of the VersionsWithType guard, add tests covering cases where a type previously would have failed this check to ensure that embedClassHandle still behaves correctly without requiring a runtime JIT.

            TypeDesc type = HandleToObject(handle);

[jkotas]

Context: #116651

[jkotas]

@davidwrighton This was introduced in https://github.com/dotnet/runtime/pull/51284/files#diff-01e22eff46505ee20d75dd64c72a9eb57d67f28f22a76258300bbe44dca59a14R2168-R2169 . Is there a reason why this check is needed for PGO?

[jkotas]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[davidwrighton]

@jkotas, yes this is needed for PGO scenarios. Notably, there is a problem where we can identify via PGO that a particular path is most desireable, and devirtualize, but if the devirtualization target isn't within the current version bubble, we cannot safely do a devirtualize. If we make this change(which I think makes sense, we need to adjust the devirtualization logic to explicitly check that it is only devirtualizing types which are safe to do so.

We don't have good coverage for this sort of scenario in any of our test suites, so actually writing the test case would be a good to have although decidedly tricky to do.

[AndyAyersMS]

we need to adjust the devirtualization logic to explicitly check that it is only devirtualizing types which are safe to do so.

Is this a similar kind of versions-with check, or something more involved?

[jkotas]

I have spent some time trying to construct a repro that fails with this change. I was not able to construct one.

Guarded devirtualization kicks in only after a method gets devirtualized successfully. Devirtualization in crossgen has number of versioning checks that abort devirtualization. In particular,

runtime/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/DevirtualizationManager.cs

Lines 95 to 100 in 0621e64

	// Impl type check
	if (!_compilationModuleGroup.VersionsWithType(implType.GetTypeDefinition()))
	{
	devirtualizationDetail = CORINFO_DEVIRTUALIZATION_DETAIL.CORINFO_DEVIRTUALIZATION_FAILED_BUBBLE_IMPL;
	return null;
	}

is very similar to the embedClassHandle check deleted in this PR. As far as I can tell, this and other checks prevent us from ever reaching embedClassHandle during guarded devirtualization for any cases that may cause problems.

@davidwrighton Am I missing some detail?