JIT: Investigate slow contexts in coreclr_tests

[jakobbotsch]

The coreclr_tests SPMI collection is about the same size as libraries_tests, yet it takes many times longer to replay. It seems like there are a small number of contexts that we spend a disproportionate time on (I can see that only a few superpmi processes are left). There is probably some quadratic blowup in the checked build somewhere.

Maybe related: #78267

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

Issue Details

---

The coreclr_tests SPMI collection is about the same size as libraries_tests, yet it takes many times longer to replay. It seems like there are a small number of contexts that we spend a disproportionate time on (I can see that only a few superpmi processes are left). There is probably some quadratic blowup in the checked build somewhere.

Maybe related: #78267

Author:	jakobbotsch
Assignees:	-
Labels:	area-CodeGen-coreclr, untriaged
Milestone:	-

[jakobbotsch]

This might just be a side effect of my change in #83005. It calls fgInsertStmtBefore a lot, which has two asserts in them:

    assert(fgBlockContainsStatementBounded(block, insertionPoint));
    assert(!fgBlockContainsStatementBounded(block, stmt, false));

This method is supposed to stop doing the expensive checks using some Compiler::compNumStatementLinksTraversed field, but that field is only initialized by rationalization, so it was some garbage and the check never ended up kicking in. I am fixing it as part of that PR.

[jakobbotsch]

Fixed by #83005