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

You are right about the code produced when tiering disabled, however, if we run the tiering and let the JIT collect profile data, we make better decision of pushing out the cold block outside of loop.

If you see below, from profile, we find out that BB07 is less likely and push it towards bottom, reducing the extra unconditional branch.

Diffs comparison of FullOpts vs. Tier 1.

As for the compactness/reuse portion of loop, that is something we can investigate further.

when tiering disabled

Unfortunately, I've been noticing this and many similar block ordering issues too (with .NET 9 regressing some further where careful ordering of the code is no longer sufficient), and tiering does not apply to NativeAOT, which is an important target. I hope that the compiler gaps like these will not be relegated to DPGO cleaning them up.

Thanks

@dotnet/jit-contrib

Unfortunately, I've been noticing this and many similar block ordering issues too (with .NET 9 regressing some further where careful ordering of the code is no longer sufficient), and tiering does not apply to NativeAOT, which is an important target. I hope that the compiler gaps like these will not be relegated to DPGO cleaning them up.

If you have any examples handy, I'd like to take a look. We have plans to address block layout more aggressively in .NET 10 (#107749), and it would be nice to have candidates like the above to improve upon. Our block layout plans are quite reliant on profile data, though the JIT frontend has some tricks to determine which blocks are important in the absence of profile data (for example, see Compiler::optSetBlockWeights, though this phase needs quite a bit of work, too).

If you have any examples handy, I'd like to take a look.

Don't have anything on hand right now but will keep an eye out next time I open Ghidra 🙂. Some of them look like this one: #93536 except torn loops or "why does this even have jump threading" cases appear under different conditions now. In any case, thanks for looking into this.

You are right about the code produced when tiering disabled, however, if we run the tiering and let the JIT collect profile data, we make better decision of pushing out the cold block outside of loop.

This is good to see - I didn't realise profile data was being used this way.

However, this shouldn't need profile data to optimise.

We have plans to address block layout more aggressively in .NET 10 (#107749), and it would be nice to have candidates like the above to improve upon.

Ok, great. If I see anything else, I'll make sure to raise issues or comment here.

With a mainline JIT, I'm still getting the same layout with tiering disabled as above. The block layout strategy we've implemented in .NET 10 relies on block weights to model the quality of a particular layout, and we've reworked upstream phases to propagate profile data changes as we modify the flowgraph. This primarily benefits PGO scenarios; for non-PGO scenarios, we still rely on block weight heuristics that prove to be subpar in cases like the above. We want to unify our approach such that we always run profile synthesis early in the frontend, and when we don't have profile data, we use heuristics-based edge likelihoods instead. Then, changes to the flowgraph will always include profile updates, regardless of whether the profile is PGO-based or entirely synthetic. For reference, this is what the current block layout strategy gives us if we turn on edge likelihood heuristics (the BBnums have since changed, so look at the BBids to compare):

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight   IBC [IL range]   [jump]                            [EH region]        [flags]
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1    100 [000..012)-> BB07(0.232),BB02(0.768) ( cond )                   i LIR IBC
BB02 [0008]  1       BB01                  0.77  77 [012..???)-> BB03(1)                 (always)                   LIR IBC internal
BB03 [0001]  2       BB06,BB02             2.23 223 [012..01E)-> BB05(0.48),BB04(0.52)   ( cond )                   i LIR IBC loophead bwd bwd-target
BB04 [0002]  1       BB03                  1.16 116 [01E..037)-> BB06(1)                 (always)                   i LIR IBC bwd
BB06 [0004]  2       BB04,BB05             2.23 223 [04E..058)-> BB03(0.656),BB07(0.344) ( cond )                   i LIR IBC bwd
BB07 [0009]  2       BB01,BB06             1    100 [058..05A)                           (return)                   i LIR IBC
BB05 [0003]  1       BB03                  1.07 107 [037..04E)-> BB06(1)                 (always)                   i LIR IBC bwd
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

The heuristics get the preferred successor of BB03 wrong, but we now get a fallthrough path through the loop. Enabling and iterating upon the likelihood heuristics wouldn't be technically difficult, but we currently lack the infrastructure to see if such changes would be a net improvement: Our microbenchmarks currently only measure PGO scenarios. I don't see us enabling heuristics + synthesis for non-PGO scenarios in .NET 10, but I do plan on pursuing this in the next release.