Reduce duplicity in GVM analysis (#83250)
authorMichal Strehovský <MichalStrehovsky@users.noreply.github.com>
Tue, 14 Mar 2023 05:32:15 +0000 (14:32 +0900)
committerGitHub <noreply@github.com>
Tue, 14 Mar 2023 05:32:15 +0000 (14:32 +0900)
commit55a09408141e4c97b866b7f36910d033d2f1f05d
tree7effe9d15f3705f2ccf7fa1dcd9ec41c2c0def3d
parent648d477858b5723059085de84966a2247cfdc0e7
Reduce duplicity in GVM analysis (#83250)

There were two very similar pieces of logic in the generic virtual method analysis. First one was deciding whether we need to emit GVM bookkeeping about the type, the second one was deciding whether the type should participate in GVM analysis (the N*M algorithm, "for each type relevant to GVM analysis" * "GVM virtual method called").

Made this into one so that it's in one spot. The interface method resolution is not cheap so this also speeds up the compilation. We should also do this for non-generic virtuals at some point.

I did a test pass with an assert that the analysis came up with the same conclusions to ensure I didn't mess up.
eng/testing/tests.singlefile.targets
src/coreclr/tools/Common/Compiler/TypeExtensions.cs
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/DependencyAnalysis/CanonicalEETypeNode.cs
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/DependencyAnalysis/EETypeNode.cs
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/DependencyAnalysis/TypeGVMEntriesNode.cs
src/libraries/tests.proj