JIT: Productize JitOptRepeat

[BruceForstall]

JitOptRepeat is a JIT configuration that repeats certain optimization phases two or more times to generate better code. Repeated optimization phases can lead to better code because the design of existing individual phases leads to a specific phase ordering: for any two distinct phases A and B, one must be run before the other. But running A before B might lead to missed optimization opportunities, just as running B before A. Repeating some phases can mitigate the phase ordering problems.

The JitOptRepeat configuration has been in the JIT for many years. In .NET 9, many correctness bugs with it were fixed; it was made available in Release builds; a performance benchmark test with JitOptRepeat enabled was created; and it was added to JIT stress modes and to the JIT "experimental" AzDO pipeline, to prevent JitOptRepeat correctness regressions. For example, see #100494 and related.

For .NET 10, the goal is to see if we can productize the use of JitOptRepeat in some form to generate better code.

Work items:

• Investigate and fix any existing correctness regressions. (For example, Assertion failed 'markedLastLoop && markedCurrLoop' #107518)
• Add a SuperPMI collection with JitOptRepeat enabled, to enable tracking of JitOptRepeat TP and code size in the CI.
• Investigate performance lab runs, especially, investigate and fix perf regressions related to enabling JitOptRepeat
• Investigate whether the right set of optimization phases is being repeated: can we repeat fewer phases, can we selectively repeat some phases?
• Implement a profitability analysis to determine which phases to repeat and when. Currently, all the repeatable phases are repeated a fixed number of times. Implement a choice, such as: only repeat if the flowgraph changes; if there are loops; etc.
• Reduce the throughput (TP) cost of running JitOptRepeat. This might be due to running it less frequently, or over fewer phases (as described above), or something else.
• Consider running JitOptRepeat only for Native AOT, when compile time is not as critical (so the TP budget might be more generous). This would change the code optimizations run between dynamic and AOT modes. Since Native AOT depends heavily for correctness of the testing in dynamic mode, this would require significantly increasing our Native AOT testing story. (Increasing our Native AOT testing might also be required to enable an AOT-only intraprocedural optimization framework that has been discussed).

[dotnet-policy-service]

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