@kunalspathak @dotnet/jit-contrib PTAL

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

With #74961, we have a collection of a run of CoreCLR tests. That makes the PMI collection of the tests mostly duplicative.

Did you actually try merging the two collections to see how many were duplicates?

My hunch is that PMI actually has a lot of unique entries that don't show up in the test runs.

Did you actually try merging the two collections to see how many were duplicates?

My hunch is that PMI actually has a lot of unique entries that don't show up in the test runs.

I didn't try, and yes, I agree there will probably be unique entries, both (1) code unused at runtime, and (2) extra generics instantiations that PMI is able to create that aren't actually used at runtime.

It's easy enough to revert this change (which is why I wanted to do this change separately), if we want to get this back.

I looked at today's spmi collection, did "mcs -dumpMap" on the coreclr_tests pmi (old) and run (new) collections, and filtered to the number of unique function signatures (this ignores different functions with the same signatures, or different JIT flags). "run" has 88288 methods, "PMI" has 56852 methods. So, there are a huge number of diffs. On a quick overview, many are what was expected: PMI has lots of cases of generics with lots of variety of instantiation arguments that aren't seen in "run". Oddly, but not unexpectedly I guess, PMI on x64 has lots of cases of Arm HW intrinsics test cases which don't exist in "run". It does seem like there are some cases in "PMI" that don't exist in "run" because they aren't used, like small accessors that presumably always get inlined in "run".