From 19381b5dc57e337fbd2a7c9d14607ec51657c3db Mon Sep 17 00:00:00 2001 From: Jakob Botsch Nielsen Date: Sun, 29 May 2022 18:34:11 +0200 Subject: [PATCH] Store actual signature types in CallArg and normalize to that type Previously, for struct args, we would use the class handle of the argument (from the IL stack) instead of the class handle from the signature. These may sometimes differ in __Canon when inlining shared code. This change switches the class handle stored in CallArg to always be the type reported back by the EE when asking about the signature. --- src/coreclr/jit/importer.cpp | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/src/coreclr/jit/importer.cpp b/src/coreclr/jit/importer.cpp index 8fc870a55d4a8..12700f4d4ad03 100644 --- a/src/coreclr/jit/importer.cpp +++ b/src/coreclr/jit/importer.cpp @@ -861,20 +861,6 @@ void Compiler::impPopCallArgs(CORINFO_SIG_INFO* sig, GenTreeCall* call) // Morph trees that aren't already OBJs or MKREFANY to be OBJs assert(ti.IsType(TI_STRUCT)); - // The argument and parameter types can be different for legitimate - // reasons, but we expect them to be compatible in those cases. One - // example where this happens is when inlining shared code into a - // non-generic function, in which case we might see the __Canon in - // the parameter type but exact types in the signature type. - // - // TODO-ARGS: Remove this quirk; we should be able to use the - // signature type that is different in the rare case above. It will - // cause positive diffs, but that is probably an indication that we - // have downstream phases that should be using - // `ClassLayout::AreCompatible` instead. - // - classHnd = ti.GetClassHandleForValueClass(); - bool forceNormalization = false; if (varTypeIsSIMD(argNode)) {