Widespread perf regressions due to RPO layout

[EgorBo]

Looks like #102343 has a lot more regressions than improvements. cc @amanasifkhalid

Regressions:

• [Perf] Windows/x64: 246 Regressions on 5/22/2024 9:27:51 PM perf-autofiling-issues#35156
• [Perf] Linux/x64: 242 Regressions on 5/22/2024 9:27:51 PM perf-autofiling-issues#35095
• [Perf] Linux/x64: 28 Regressions on 5/21/2024 3:15:28 PM perf-autofiling-issues#35092
• [Perf] Linux/x64: 3 Regressions on 5/22/2024 5:24:07 PM perf-autofiling-issues#35094
• [Perf] Windows/arm64: 9 Regressions on 5/22/2024 9:27:51 PM perf-autofiling-issues#35381
• [Perf] Windows/arm64: 22 Regressions on 5/22/2024 5:54:51 PM perf-autofiling-issues#35380
• [Perf] Linux/arm64: 135 Regressions on 5/22/2024 5:54:51 PM perf-autofiling-issues#35370

Improvements:

• [Perf] Linux/x64: 142 Improvements on 5/22/2024 9:27:51 PM perf-autofiling-issues#35107
• [Perf] Windows/x64: 111 Improvements on 5/22/2024 9:27:51 PM perf-autofiling-issues#35164
• [Perf] Windows/x64: 42 Improvements on 5/21/2024 3:15:28 PM perf-autofiling-issues#35161
• [Perf] Windows/x64: 10 Improvements on 5/22/2024 5:24:07 PM perf-autofiling-issues#35163
• [Perf] Linux/arm64: 49 Improvements on 5/22/2024 5:54:51 PM perf-autofiling-issues#35375
• [Perf] Linux/arm64: 11 Improvements on 5/22/2024 6:50:08 AM perf-autofiling-issues#35374

NOTE: use Test report links, it looks like "all time history" and the images are a bit out of date.

[dotnet-policy-service]

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

[amanasifkhalid]

@EgorBo Thanks for opening this. I haven't spent too much time looking at the regressions yet, but based on the larger ones I've looked at, I think we need a more general/powerful implementation of #102461. Take GuardedDevirtualization.TwoClassVirtual.Call for instance, which regressed by over 60% on Windows x64 (GuardedDevirtualization.ThreeClassVirtual.Call regressed for similar reasons). Before reordering, the blocks look like this:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight    IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1      18 [000..00E)-> BB07(0.00595),BB02(0.994)   ( cond )                     i IBC idxlen
BB02 [0009]  1       BB01                  0.99   18 [00E..???)-> BB03(1)                 (always)                     IBC internal idxlen
BB03 [0001]  2       BB02,BB06           167.07 3007 [00E..00E)-> BB05(0.07),BB04(0.93)   ( cond )                     i IBC loophead idxlen bwd bwd-target
BB04 [0005]  1       BB03                155.37 2797 [???..???)-> BB06(1)                 (always)                     i IBC internal idxlen nullcheck bwd
BB05 [0006]  1       BB03                 11.69  211 [???..???)-> BB06(1)                 (always)                     i IBC internal hascall gcsafe idxlen bwd
BB06 [0004]  2       BB04,BB05           167.07 3007 [00E..024)-> BB03(0.994),BB07(0.00595)   ( cond )                     i IBC idxlen bwd
BB07 [0010]  2       BB01,BB06             1.00   18 [024..026)                           (return)                     i IBC
BB09 [0011]  0                             0         [???..???)                           (throw )                     i rare keep internal
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

The interesting ones are BB03-BB06, which comprise a loop. The hot path is BB03->BB04->BB06->BB03; moving BB05 out-of-line to make the hot path branchless (except for the backward jump) would be ideal. The old layout does this:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight    IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1      18 [000..00E)-> BB07(0.00595),BB02(0.994)   ( cond )                     i IBC idxlen
BB02 [0009]  1       BB01                  0.99   18 [00E..???)-> BB03(1)                 (always)                     IBC internal idxlen
BB03 [0001]  2       BB02,BB06           167.07 3007 [00E..00E)-> BB05(0.07),BB04(0.93)   ( cond )                     i IBC loophead idxlen bwd bwd-target
BB04 [0005]  1       BB03                155.37 2797 [???..???)-> BB06(1)                 (always)                     i IBC internal idxlen nullcheck bwd
BB06 [0004]  2       BB04,BB05           167.07 3007 [00E..024)-> BB03(0.994),BB07(0.00595)   ( cond )                     i IBC idxlen bwd
BB07 [0010]  2       BB01,BB06             1.00   18 [024..026)                           (return)                     i IBC
BB05 [0006]  1       BB03                 11.69  211 [???..???)-> BB06(1)                 (always)                     i IBC internal hascall gcsafe idxlen bwd
BB09 [0011]  0                             0         [???..???)                           (throw )                     i rare keep internal
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

In the new layout, fgMoveBackwardJumpsToSuccessors only considers moving backward unconditional jumps, so BB05 remains in the way of the hot path:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight    IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1      18 [000..00E)-> BB07(0.00595),BB02(0.994)   ( cond )                     i IBC idxlen
BB02 [0009]  1       BB01                  0.99   18 [00E..???)-> BB03(1)                 (always)                     IBC internal idxlen
BB03 [0001]  2       BB02,BB06           167.07 3007 [00E..00E)-> BB05(0.07),BB04(0.93)   ( cond )                     i IBC loophead idxlen bwd bwd-target
BB04 [0005]  1       BB03                155.37 2797 [???..???)-> BB06(1)                 (always)                     i IBC internal idxlen nullcheck bwd
BB05 [0006]  1       BB03                 11.69  211 [???..???)-> BB06(1)                 (always)                     i IBC internal hascall gcsafe idxlen bwd
BB06 [0004]  2       BB04,BB05           167.07 3007 [00E..024)-> BB03(0.994),BB07(0.00595)   ( cond )                     i IBC idxlen bwd
BB07 [0010]  2       BB01,BB06             1.00   18 [024..026)                           (return)                     i IBC
BB09 [0011]  0                             0         [???..???)                           (throw )                     i rare keep internal
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

I think modifying fgMoveBackwardJumpsToSuccessors to consider forward jumps would be a good start to chipping away at these regressions. However, moving BB06 up to BB04 would break up the former's fallthrough into BB07. That's ok, since that's part of the slow path, but we probably want to update the cost check in fgMoveBackwardJumpsToSuccessors to also check if moving the target block will break up fallthrough into its next block, and whether the edge weights deem it's worth it.

Thoughts on this? cc @AndyAyersMS for visibility. Thanks!

[AndyAyersMS]

I would suggest we list all the regressions in rank order and then investigate at least the top 20 or so. We also should see what the arm64 data looks like.

Based on the above and the the other fixup actions, it feels like we are getting to the point where we may actually want to create the explicit cost/benefit model to assess incremental improvements. We have a layout configuration A, and some proposed alternate B. Which is better?

If you want to try to build this out, we should talk. The general model is something like the following:

• identify 3 cut points in the linear chain of blocks (creating 4 segments overall). First segment must contain at least the entry block; last one can be empty.
• swap the middle two segments; if that is lower cost, make that the new configuration
• repeat until you can't find any more improvements or give up (drive to local minima)
• (or just limit yourself to one pass or something to keep the TP under control)
• (the someday refinement: occasionally allow reorderings that drive the cost up, to try and find a global minimum)

Since there are just 3 cut points, if you have an initial cost model it's not too hard to compute the delta to the new cost model, you (mostly) just need to recost the segment-ending blocks (if the cost model is block-size sensitive then perhaps a bit more, but I don't think we have good size estimates yet?)

For the time being the "identify" step can be finding a single misplaced block and a new proposed location, and then seeing if the cost improves.

[amanasifkhalid]

I would suggest we list all the regressions in rank order and then investigate at least the top 20 or so.

Sorry about the delay in getting back to this; the script we typically use to collate regression data doesn't seem to work since the perflab test report URLs changed, so I hacked up my own script. Here are the top 20 regressions on Windows x64:

Name	Base	Test	Ratio
System.Collections.Sort.Array_Comparison	9.19 μs	17.66 μs	1.92
System.Collections.Sort.Array_ComparerClass	9.85 μs	17.36 μs	1.76
GuardedDevirtualization.ThreeClassVirtual.Call	3.82 ns	6.56 ns	1.72
System.Linq.Tests.Perf_Enumerable.SelectToList	125.92 ns	209.71 ns	1.67
System.Collections.Sort.LinqQuery	17.06 μs	28.35 μs	1.66
GuardedDevirtualization.TwoClassVirtual.Call	1.75 ns	2.86 ns	1.63
LinqBenchmarks.Count00ForX	91.54 ms	147.83 ms	1.61
System.Collections.Sort.LinqOrderByExtension	17.45 μs	28.14 μs	1.61
System.Text.Encodings.Web.Tests.Perf_Encoders.EncodeUtf8	53.46 ns	85.59 ns	1.6
System.Collections.Sort.LinqOrderByExtension	20.34 μs	32.52 μs	1.6
System.Memory.Span.Reverse	32.25 ns	50.97 ns	1.58
System.Tests.Perf_Random.NextBytes_unseeded	170.90 ns	244.84 ns	1.43
System.Tests.Perf_Random.NextBytes_span_unseeded	171.98 ns	244.27 ns	1.42
System.Memory.Span.Reverse	3.21 ns	4.54 ns	1.41
System.Collections.Sort.LinqOrderByExtension	16.82 μs	23.40 μs	1.39
System.Text.Perf_Ascii.ToLower_Chars	27.93 ns	38.72 ns	1.39
System.Collections.Perf_Frozen.ToFrozenDictionary	32.28 μs	44.49 μs	1.38
Benchstone.BenchI.CSieve.Test	4.25 ms	5.87 ms	1.38
System.Text.Perf_Ascii.Equals_Bytes	4.55 ns	6.23 ns	1.37
System.Text.Perf_Ascii.ToUpper_Chars	27.64 ns	37.66 ns	1.36

And on Linux x64:

Name	Base	Test	Ratio
System.IO.Hashing.Tests.Crc32_AppendPerf.Append	335.26 ns	1.07 μs	3.2
GuardedDevirtualization.ThreeClassVirtual.Call	1.07 ns	2.90 ns	2.72
GuardedDevirtualization.ThreeClassVirtual.Call	1.01 ns	2.73 ns	2.71
GuardedDevirtualization.ThreeClassVirtual.Call	1.07 ns	2.91 ns	2.71
GuardedDevirtualization.ThreeClassVirtual.Call	1.01 ns	2.71 ns	2.69
GuardedDevirtualization.ThreeClassVirtual.Call	1.01 ns	2.71 ns	2.69
GuardedDevirtualization.ThreeClassVirtual.Call	1.07 ns	2.87 ns	2.68
System.IO.Hashing.Tests.Crc32_AppendPerf.Append	8.21 ns	21.65 ns	2.64
System.IO.Hashing.Tests.Crc32_AppendPerf.Append	15.58 ns	38.16 ns	2.45
GuardedDevirtualization.TwoClassVirtual.Call	1.46 ns	3.22 ns	2.21
System.Tests.Perf_String.TrimEnd	1.69 ns	3.18 ns	1.88
GuardedDevirtualization.TwoClassVirtual.Call	1.23 ns	2.30 ns	1.86
Benchstone.BenchF.NewtR.Test	55.69 ms	102.90 ms	1.85
LinqBenchmarks.Count00ForX	58.01 ms	103.57 ms	1.79
System.Collections.Sort.Array_ComparerClass	8.31 μs	14.71 μs	1.77
System.Collections.Sort.Array_Comparison	7.32 μs	12.29 μs	1.68
System.Tests.Perf_String.TrimStart_CharArr	2.52 ns	4.12 ns	1.64
System.Collections.Sort.Array_ComparerClass	7.15 μs	11.61 μs	1.62
System.Collections.IterateFor.IList	287.08 ns	454.48 ns	1.58
System.Text.Perf_Ascii.ToUpper_Bytes	11.49 ns	17.77 ns	1.55

I'll start digging into the overlapping benchmarks (this explains GuardedDevirtualization.TwoClassVirtual.Call and GuardedDevirtualization.ThreeClassVirtual.Call already, and I suspect the theme of hot paths being polluted by a relatively cold (but not "cold" cold) jump will continue to come up).

[amanasifkhalid]

I'm seeing the same theme of interleaving hot and colder blocks throughout these regressions. The RPO-based layout on its own doesn't seem to leverage edge weights heavily enough, and while fgMoveBackwardJumpsToSuccessors does consider edge weights, its backward jump limitation is blocking lots of potentially profitable moves. System.Memory.Span<Int32>.Reverse illustrates this succinctly. Here's what the new layout does:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight   IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1    100 [000..00A)-> BB05(0.2),BB02(0.8)     ( cond )                     i IBC
BB02 [0001]  1       BB01                  0.80  80 [00A..00B)-> BB04(0.2),BB03(0.8)     ( cond )                     i IBC hascall
BB03 [0018]  1       BB02                  0.64  64 [00A..00B)-> BB04(1)                 (always)                     i IBC hascall gcsafe
BB04 [0019]  2       BB02,BB03             0.80  80 [00A..00B)-> BB06(1)                 (always)                     i IBC hascall gcsafe
BB05 [0003]  1       BB01                  0.20  20 [???..???)-> BB06(1)                 (always)                     i IBC internal hascall
BB06 [0002]  2       BB04,BB05             1    100 [01D..01E)                           (return)                     i IBC tail-succ
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

Notice how BB06 can be reached from BB04 and BB05, and the former is hotter, but doesn't fall into BB06. If fgMoveBackwardJumpsToSuccessors considered forward jumps, it would move BB06 up. For a more involved example, let's look at System.Text.Perf_Ascii.Equals_Bytes. Here's the new layout:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight   IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1    100 [000..001)-> BB03(0.99),BB02(0.00994)  ( cond )                     i IBC
BB03 [0004]  1       BB01                  0.99  99 [000..001)-> BB04(1)                 (always)                     i IBC idxlen nullcheck
BB02 [0003]  1       BB01                  0.01   1 [000..001)-> BB04(1)                 (always)                     i IBC
BB04 [0005]  2       BB02,BB03             1    100 [000..001)-> BB06(0.99),BB05(0.00994)  ( cond )                     i IBC
BB06 [0009]  1       BB04                  0.99  99 [000..001)-> BB07(1)                 (always)                     i IBC idxlen nullcheck
BB05 [0008]  1       BB04                  0.01   1 [000..001)-> BB07(1)                 (always)                     i IBC
BB07 [0010]  2       BB05,BB06             1    100 [000..000)-> BB09(0),BB08(1)         ( cond )                     i IBC
BB08 [0012]  1       BB07                  1    100 [000..000)-> BB10(1)                 (always)                     i IBC internal hascall gcsafe
BB10 [0014]  2       BB08,BB09             1    100 [01C..01C)                           (return)                     i IBC
BB09 [0013]  1       BB07                  0      0 [000..000)-> BB10(1)                 (always)                     i IBC rare internal
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

If we considered moving forward jumps, we'd have the following decision tree:

• BB03->BB04 is hotter than BB02->BB04, so move BB04 up.
• BB04->BB06 is hot, and BB04 is the only pred of BB06, but BB02 is now between them, so move BB06 up; we're basically bubbling BB02 down the block list. Now we have this:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight   IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1    100 [000..001)-> BB03(0.99),BB02(0.00994)  ( cond )                     i IBC
BB03 [0004]  1       BB01                  0.99  99 [000..001)-> BB04(1)                 (always)                     i IBC idxlen nullcheck
BB04 [0005]  2       BB02,BB03             1    100 [000..001)-> BB06(0.99),BB05(0.00994)  ( cond )                     i IBC
BB06 [0009]  1       BB04                  0.99  99 [000..001)-> BB07(1)                 (always)                     i IBC idxlen nullcheck
BB02 [0003]  1       BB01                  0.01   1 [000..001)-> BB04(1)                 (always)                     i IBC
BB05 [0008]  1       BB04                  0.01   1 [000..001)-> BB07(1)                 (always)                     i IBC
BB07 [0010]  2       BB05,BB06             1    100 [000..000)-> BB09(0),BB08(1)         ( cond )                     i IBC
BB08 [0012]  1       BB07                  1    100 [000..000)-> BB10(1)                 (always)                     i IBC internal hascall gcsafe
BB10 [0014]  2       BB08,BB09             1    100 [01C..01C)                           (return)                     i IBC
BB09 [0013]  1       BB07                  0      0 [000..000)-> BB10(1)                 (always)                     i IBC rare internal
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

• BB06->BB07 is hotter than BB05->BB07, so move BB07 up. We've bubbled BB02 and BB05 down.
• BB07->BB08 is hot, and BB07 is the only pred of BB08, so move BB08 up.
• BB08->BB10is hot, andBB10's other pred doesn't fall into it anyway, so move BB10` up. Here's what we have:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight   IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1    100 [000..001)-> BB03(0.99),BB02(0.00994)  ( cond )                     i IBC
BB03 [0004]  1       BB01                  0.99  99 [000..001)-> BB04(1)                 (always)                     i IBC idxlen nullcheck
BB04 [0005]  2       BB02,BB03             1    100 [000..001)-> BB06(0.99),BB05(0.00994)  ( cond )                     i IBC
BB06 [0009]  1       BB04                  0.99  99 [000..001)-> BB07(1)                 (always)                     i IBC idxlen nullcheck
BB07 [0010]  2       BB05,BB06             1    100 [000..000)-> BB09(0),BB08(1)         ( cond )                     i IBC
BB08 [0012]  1       BB07                  1    100 [000..000)-> BB10(1)                 (always)                     i IBC internal hascall gcsafe
BB10 [0014]  2       BB08,BB09             1    100 [01C..01C)                           (return)                     i IBC
BB02 [0003]  1       BB01                  0.01   1 [000..001)-> BB04(1)                 (always)                     i IBC
BB05 [0008]  1       BB04                  0.01   1 [000..001)-> BB07(1)                 (always)                     i IBC
BB09 [0013]  1       BB07                  0      0 [000..000)-> BB10(1)                 (always)                     i IBC rare internal
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

• BB10 has no successors.
• BB02 is a backward jump, but BB03->BB04 is hotter, so don't move anything.
• Ditto BB05.
• BB09 is rarely-run, so we don't care about it.

For a few other short examples, just to build my case, here's the new layout of System.Text.Encodings.Web.Tests.Perf_Encoders.EncodeUtf8:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight   IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1    100 [000..001)-> BB03(0.99),BB02(0.00994)  ( cond )                     i IBC
BB03 [0004]  1       BB01                  0.50  50 [000..001)-> BB04(1)                 (always)                     i IBC idxlen nullcheck
BB02 [0003]  1       BB01                  0.00   0 [000..001)-> BB04(1)                 (always)                     i IBC
BB04 [0005]  2       BB02,BB03             1    100 [000..000)-> BB06(1),BB05(0)         ( cond )                     i IBC
BB06 [0009]  1       BB04                  0.50  50 [000..000)-> BB07(1)                 (always)                     i IBC internal idxlen nullcheck
BB07 [0013]  2       BB05,BB06             1    100 [027..027)                           (return)                     i IBC hascall gcsafe
BB05 [0008]  1       BB04                  0      0 [000..000)-> BB07(1)                 (always)                     i IBC rare internal
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

And for System.String.TrimWhiteSpaceHelper from System.Tests.Perf_String.TrimEnd (in particular, we could consider creating fallthrough for BB29->BB23->BB27->BB28):

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight    IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1    2261 [000..010)-> BB12(0.092),BB02(0.908) ( cond )                     i IBC idxlen
BB02 [0001]  1       BB01                  0.91 2053 [010..014)-> BB11(0),BB03(1)         ( cond )                     i IBC idxlen
BB03 [0246]  2       BB02,BB09             1.82 4120 [014..015)-> BB07(0.52),BB08(0.48)   ( cond )                     i IBC idxlen bwd
BB07 [0041]  1       BB03                  0.95 2142 [014..015)-> BB14(0.498),BB09(0.502) ( cond )                     i IBC bwd
BB08 [0055]  1       BB03                  1.57 3560 [014..022)-> BB14(0.498),BB09(0.502) ( cond )                     i IBC bwd
BB09 [0003]  2       BB07,BB08             1.82 4120 [022..02F)-> BB03(1),BB10(0)         ( cond )                     i IBC hascall idxlen bwd
BB14 [0011]  2       BB07,BB08             0.91 2053 [???..???)-> BB12(1)                 (always)                     i IBC internal hascall
BB12 [0005]  3       BB01,BB11,BB14        1.00 2261 [02F..034)-> BB23(0.000442),BB13(1)  ( cond )                     i IBC
BB13 [0006]  1       BB12                  1.00 2260 [034..03F)-> BB21(1)                 (always)                     i IBC idxlen
BB21 [0009]  2       BB13,BB20             1.01 2282 [051..055)-> BB15(1),BB22(0)         ( cond )                     i IBC bwd bwd-src
BB15 [0007]  1       BB21                  1.01 2282 [03F..040)-> BB18(0.52),BB19(0.48)   ( cond )                     i IBC loophead idxlen bwd bwd-target
BB18 [0169]  1       BB15                  0.52 1187 [03F..040)-> BB29(0.99),BB20(0.00964)  ( cond )                     i IBC bwd
BB19 [0183]  1       BB15                  0.87 1972 [03F..04D)-> BB29(0.99),BB20(0.00964)  ( cond )                     i IBC bwd
BB29 [0013]  2       BB18,BB19             1.00 2260 [???..???)-> BB23(1)                 (always)                     i IBC internal hascall
BB20 [0008]  2       BB18,BB19             0.01   22 [04D..051)-> BB21(1)                 (always)                     i IBC hascall bwd
BB23 [0010]  3       BB12,BB22,BB29        1.00 2261 [055..056)-> BB27(0.884),BB24(0.116) ( cond )                     i IBC hascall idxlen
BB27 [0243]  1       BB23                  0.88 1999 [055..056)-> BB28(1)                 (always)                     i IBC
BB24 [0240]  1       BB23                  0.12  262 [055..056)-> BB26(0.0461),BB25(0.954)  ( cond )                     i IBC
BB25 [0241]  1       BB24                  0.11  250 [055..056)-> BB28(1)                 (always)                     i IBC hascall gcsafe
BB26 [0242]  1       BB24                  0.01   12 [055..056)-> BB28(1)                 (always)                     i IBC
BB28 [0244]  3       BB25,BB26,BB27        1.00 2261 [055..05E)                           (return)                     i IBC
BB10 [0247]  1       BB09                  0       0 [???..???)-> BB11(1)                 (always)                     IBC rare internal
BB11 [0012]  2       BB02,BB10             0       0 [???..???)-> BB12(1)                 (always)                     i IBC rare internal hascall
BB22 [0014]  1       BB21                  0       0 [???..???)-> BB23(1)                 (always)                     i IBC rare internal hascall
BB30 [0248]  0                             0         [???..???)                           (throw )                     i rare keep internal
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

And for System.Tests.Perf_Random.NextBytes_unseeded (an interesting case in that the exceptional path is the hot path based on edge weights, even though the throw block has a weight of 0 due to RyuJIT's flowgraph semantics -- I guess if our post-RPO changes suggest a "rarely-run" block should be moved up because it isn't that rare, maybe we should unmark it as not rare?):

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight   IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1    100 [000..003)-> BB03(0.2),BB02(0.8)     ( cond )                     i IBC
BB03 [0002]  1       BB01                  1    100 [00A..017)                           (return)                     i IBC jmp hascall hist
BB02 [0001]  1       BB01                  0      0 [003..00A)                           (throw )                     i IBC rare hascall gcsafe
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

Based on the above and the the other fixup actions, it feels like we are getting to the point where we may actually want to create the explicit cost/benefit model to assess incremental improvements.

I'd be interested in pursuing this, though based on the above, I think it might be worthwhile trying to implement a more general post-RPO pass that does the moves I described above, since it seems simple enough.

[AndyAyersMS]

I am surprised some of these are so large. Do we have any results for AMD HW? All the reports above are for Intel.

[AndyAyersMS]

ADX data for the three class virtual test. Strongly suggests that this may be JCC errata kicking in.

Of course this is a two-way street, some of the improvements may be like this too.

[AndyAyersMS]

Randomly looking at improvements, it seems most are also intel only. But not all. Here's Benchstone.BenchI.BubbleSort2.Test

@DrewScoggins is looking into whether there are unfiled AMD64 reports out there. From what I can tell the newer AMD64 hardware is mostly indifferent.