Runtime: [JIT] Allow the developer to instruct the JIT to do not reorder goto based blocks.

[redknightlois]

When manually rearranging blocks you end up in situations where you know best what the arrangement is. I hit one of those cases when optimizing memory diffing. Example: https://youtu.be/DD3w66Ff8Ms?t=20859

Give the JIT a hint could help.

Jit.DoNotReorder()

or

[JitAttribute(JitMethod.DoNotReorder)]

Details on all the tricks can be found at: https://www.youtube.com/watch?time_continue=18053&v=DD3w66Ff8Ms

cc @AndyAyersMS

[RussKeldorph]

@dotnet/jit-contrib

[sandreenko]

I think it won't be necessary soon If we are planning to do tiered compilation that collects branch counters. A simple block layout algorithm with PGO should order blocks better than manual hints.

[redknightlois]

@sandreenko agree. Question is: how far in the horizon is a ready for production PGO tiered JIT with block layout support. That's yesterday production code :)

[4creators]

@tannergooding This could be one of the use cases for compiler hints API you have proposed.

[AndyAyersMS]

My preference would be to stick with execution frequency hints. I believe you can use them to accomplish what you want.

Frequency hints have the benefit that they can apply unambiguously to some point in code and hence become a property of a particular block (or set of blocks). Also they fit in well with our nascent thinking on how to model profile data in the flow graph (hopefully we'll have write-ups on this available before too long).

Block ordering is a relative concept between or among some set of blocks, and the concept is somewhat alien and more difficult to model internally, as blocks are frequently invented from whole cloth / split / merged / duplicated.

[redknightlois]

Make sense! Probably we would need Jit.AlignLoop too, but that is another story.

[CarolEidt]

Probably we would need Jit.AlignLoop too, but that is another story.

That could make benchmark analysis a little easier :-)