Convert isExactType check to JIT/EE interface call

[jkotas]

The approximation of isExactType from class flags had false positives (correctness) and false negatives issues. Converting it to JIT/EE interface method fixes them both.

Fixes #97134

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The approximation of isExactType from class flags had false positives (correctness) and false negatives issues. Converting it to JIT/EE interface method fixes them both.

Fixes #97134

Author:	jkotas
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[jkotas]

cc @dotnet/jit-contrib

[EgorBo]

It's a coincidence, but in https://github.com/dotnet/runtime/pull/97387/files I currently have a failing test that fails because IsExactClass returns true for a class with [TypeIdentifier] and I assume this PR will fix it. The reason current jit's cast expansion logic is not hitting this issue becuase it doesn't try to expand CORINFO_HELP_ISINSTANCEOFANY for exact classes

[EgorBo]

Does IsExactType return true for int[]? I assume no and wonder if it results in some jit-diffs (we can run MihuBot once PR passes CI)

[jkotas]

Does IsExactType return true for int[]?

It does not and it cannot not. int[], uint[] and arrays of int/uint backed enums are interchangeable.

[jkotas]

I assume no and wonder if it results in some jit-diffs

The JIT approximation returned false for int[] as well.

I agree that it is interesting to get jit-diff.

[EgorBo]

There is also getExactClasses API which is implemented only for NativeAOT at the moment - I wonder if it doesn't respect type variance too. JIT might use that API to optimize casts and it might skip the fallback call because it assumes it's the only type that can pass the cast.

[jkotas]

JIT might use that API to optimize casts and it might skip the fallback call

Do you mean this place

runtime/src/coreclr/jit/importer.cpp

Lines 5483 to 5484 in d250dcc

	(info.compCompHnd->getExactClasses(pResolvedToken->hClass, 1, &actualImplCls) == 1) &&
	(actualImplCls != NO_CLASS_HANDLE) && impIsClassExact(actualImplCls))

? The code checks whether the implementation is actually exact. I do not see a problem there. (There may be a naming confusion - getExactClasses vs. isExactType do not use "exact" to mean the same thing.)

[EgorBo]

JIT might use that API to optimize casts and it might skip the fallback call

Do you mean this place

runtime/src/coreclr/jit/importer.cpp

Lines 5483 to 5484 in d250dcc

	(info.compCompHnd->getExactClasses(pResolvedToken->hClass, 1, &actualImplCls) == 1) &&
	(actualImplCls != NO_CLASS_HANDLE) && impIsClassExact(actualImplCls))

? The code checks whether the implementation is actually exact. I do not see a problem there. (There may be a naming confusion - getExactClasses vs. isExactType do not use "exact" to mean the same thing.)

Yes, I meant that case - I agree it's ok since it checks isExact explicitly 👍

There may be a naming confusion

Agree, getExactClasses was named like that as an opposite to getLikelyClasses

[EgorBo]

@MihuBot

[EgorBo]

@jkotas an unrelated question:

Currently, for

var result = (MySealedClass)obj;

jit emits something like this:

if (obj.GetType() == typeof(MySealedClass))
    result = obj;
else
   CORINFO_HELP_CHKCASTCLASS(obj, MySealedClass)
   ret3 // always throw anyway

Can we hit here the same issue we hit recently with version bubbles in R2R if MySealedClass becomes non-sealed in a new version? or isExactClass won't return true for it even if has sealed?

[jkotas]

isExactClass won't return true for it even if has sealed?

Yes. IsEffectivelySealed for R2R returns true only if the type is in the same version bubble:

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

Lines 18 to 21 in d250dcc

	public override bool IsEffectivelySealed(TypeDesc type)
	{
	return _compilationModuleGroup.VersionsWithType(type) && base.IsEffectivelySealed(type);
	}

[jkotas]

/azp run runtime-coreclr outerloop, runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

No jit-diffs MihuBot/runtime-utils#228 (comment)

[EgorBo]

the build-in-progress jobs seem to stuck? 10h for the NativeAOT one

[jkotas]

the build-in-progress jobs seem to stuck? 10h for the NativeAOT one

Received request to deprovision: The request was cancelled by the remote provider.

These legs passed in previous runs. I do not think we need to retry.