Re-revert "Fold overflow operations in value numbering"

[SingleAccretion]

This PR reintroduces changes from #50450, except for folding of the helpers for casts - both the VN part and morph part have been left out.

I have manually verified that test cases from #51381, #51346 and #51380 are no longer reproducible with this version of the change, but a full run of the legs that run these tests would be required before this can be merged.

I have decided to reintroduce one part of #50450 first instead of going straight for the removal of folding for problematic cases because I think the changes in #50450 around gtFoldExprConst & CheckedOps will be helpful when addressing that issue.

The code has been left as-is expect for some folding of formatting fixups into their respective commits, two /*printResult*/ comments, and moving commits disabling the test on Mono and adding vartypesdef.h earlier in the commit chain.

Draft pending green regular CI and verification that diffs are as expected.

[SingleAccretion]

Diffs are as expected, no changes with respect to #50450 modulo expected (now not folded) cases in tests.

[SingleAccretion]

Failures look unrelated, so switching as ready for review.

[BruceForstall]

@dotnet/jit-contrib PTAL

[AndyAyersMS]

@sandreenko can you review this?

[AndyAyersMS]

@sandreeko let me know if you can't get to this soon....

[SingleAccretion]

Rebased to resolve a conflict.

[sandreenko]

/azp run runtime-coreclr jitstress, runtime-coreclr outerloop, runtime-libraries-coreclr outerloop, runtime-coreclr libraries-jitstress

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[sandreenko]

LGTM, I like the new code better, and if testing does not show anything bad that I am good with this change.

[AntonLapounov]

Thank you for incorporating feedback. I have also some suggestions on the long comment in utils.cpp.

[SingleAccretion]

Despite not all stress/outerloop legs having the chance to finish there were (I have to say, quite) some failures. Some look like known issues (#53042, #52954), others I do not understand (Discovered: System.Runtime.Handles.Tests (found 0 of 14 test cases) - consequence of the job being cancelled?), yet others look like something I should investigate (System.Linq.Expressions.Tests: Stack overflow.) - which I will do.

[sandreenko]

Discovered: System.Runtime.Handles.Tests (found 0 of 14 test cases) - consequence of the job being cancelled?

Yes.

Let's start them again and wait for the results.

[sandreenko]

/azp run runtime-coreclr jitstress, runtime-coreclr outerloop, runtime-libraries-coreclr outerloop, runtime-coreclr libraries-jitstress

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[SingleAccretion]

Starting to classify the failures:

runtime-coreclr jitstress:
1. Libraries Test Run checked coreclr Linux x64 Release - segfault, could be related.
2. Libraries Test Run checked coreclr windows arm64 Release - CodeDom tests fail with NREs. Looks like #53042.

runtime-coreclr outerloop:
3. A lot of structreturn failures, look like #52954.

runtime-libraries-coreclr outerloop
4. System.Linq.Expressions.Tests fail with SO (see below).
Reproduces on Windows x64, Checked Debug Jit (with TC off - does not matter because dynamic methods are always Tier1). Does not Does reproduce on the base runtime (I was wrongly testing Checked base). Turns out this test has a history: #21374. Looks very possible that this PR has in some way increased the stack space required to compile the method. Working hypothesis: gtFoldExprConst, due to the new calls, now requires more stack space. That said, it is puzzling it fails so readily - the test only creates ~200 nodes, 100 calls to gtFoldExprConst, and apparently reserves 128 KB of stack.

Some further investigation appears not to support this. I made a method just like one in the test (100 adds that form a deep tree with 200 nodes), and tested the following code:

var t = new Thread(x => RuntimeHelpers.PrepareMethod(type.GetMethod("Problem", flags).MethodHandle), X * 1024);
t.Start();

For both base and diff, if X is less than 321, SO happens, and does not happen otherwise.

5. A bunch of Discovered: ... (found 0 of X test cases) type failures (I double-checked that I am looking at the restarted run). I think the cause is there is no category=OuterLoops for these tests - ?
6. Libraries Build Linux x64 Debug, System.Runtime.Tests.dll, ./RunTests.sh: line 162: 1193 Killed <the test process> - puzzling.

[sandreenko]

there are strange spmi failures on arm64 apple (link ) that I did not see before, will take a look.
Edit: it was failing before, not related

runtime-coreclr outerloop:
3. A lot of structreturn failures, look like #52954.

it was just resolved, lets trigger the job again to clear the output.

5. A bunch of Discovered: ... (found 0 of X test cases) type failures (I double-checked that I am looking at the restarted run). I think the cause is there is no category=OuterLoops for these tests - ?

could you give me an example?

[sandreenko]

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

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[SingleAccretion]

could you give me an example?

Yep. https://github.com/dotnet/runtime/pull/51440/checks?check_run_id=2669273261: log 1, log 2, log 3.

[SingleAccretion]

it was just resolved, lets trigger the job again to clear the output.

Hmm, I think I need to rebase for that one, don't I?

[sandreenko]

Hmm, I think I need to rebase for that one, don't I?

I could be wrong but I expect that runs that are triggered via /azp run are merged with the current main head, just like the default runtime-dev-innerloop.

From the log:
https://dev.azure.com/dnceng/public/_build/results?buildId=1156405&view=logs&j=e2176d62-3fb6-5179-e340-9cc434b4aa5a&t=a3ddac58-ea20-55ce-a88e-6de49e130568&l=596
Merge 7027588 into 959c327

[sandreenko]

Ok, so all runtime-coreclr outerloop/jitstress failures are not related (#53267 for outerloop).

[SingleAccretion]

Final bucketing for failures of libraries tests.

runtime-libraries-coreclr outerloop:

1. S.L.E SO is a persistent failure. I looked at the pipeline, and it failed here, however, did not fail here, on 21st, suggesting something introduced it recently, but it should not be this PR (I am still looking at it).
2. Failures for Libraries Build OSX arm64 Debug all have the same pattern: 0 tests discovered and python crashes at the end: log 1, log 2, log 3.
3. Libraries Build Linux x64 Debug:

• More 0 tests + python crashed failures: log 1, log 2.
• System.Runtime.Tests killed for OOM: log. Identical failure also seen here - log.
• System.Runtime.Tests killed: log. Too seen here: log

runtime-coreclr libraries-jitstress:

1. CodeDom tests fail with NREs - #53042.
2. Libraries Test Run checked coreclr Linux x64 Release: System.Runtime.Tests fail with a segfault (log). Also seen in a more recent run.

[sandreenko]

Thanks @SingleAccretion for the detailed analysis and addressing the feedback.
I am going to merge it now, we should not have a global issue as we had after the first merge so even if something pops up later we should be able to disable individual tests and resolve the issues without reverting this work.