JIT: consider priority driven importation

[AndyAyersMS]

The order of importation of blocks can impact the allocation of fast dictionary slots (see notes in #11971).

The jit currently imports IL code via an implicit depth first search:

• impImportBlock pends successors in GetSucc order
• For BBJ_COND, GetSucc returns fall through blocks before jumped-to blocks
• impImportBlockPending prepends to the pending block list

As a result dictionary slot assignments might be favorably influenced by trying to import the most performance-sensitive blocks first.

Note this may also be mitigated or fixed in the runtime if we can determine the number of needed slots.

Some ideas:

Short term

impImportBlock can try and prioritize among its successors via some heuristic. For instance a branch guarding a return might be considered a fast path.

Long term

Because of evaluation stack modelling the jit can't simply start importation at any point -- blocks that are not stack empty on entry must wait until at least one predecessor has been imported (in fact this is how we discover if a block is stack empty, so in the current importer the only block that we can safely start with is the entry block). But we could do a better job of stack modelling during the IL opcode prescan (where we build the flow graph) and determine the set of stack empty blocks up front.

And, if in conjunction, we ran profile synthesis, or imported IBC profile data, or had a lower tier jit producing profile data that we could access, we'd have a priority ordering for blocks.

category:cq
theme:inlining
skill-level:expert
cost:large

[jkotas]

Note that there is a similar problem at larger scope: The order in which generic methods get compiled can affect whether they get the fast slots or not. People did notice this number of times - there are bugs on this in the internal bug database.

I think we should rather fix this in the runtime by making the number of the fast generic slots dynamically adjustable.

[AndyAyersMS]

I agree, but was not sure if/when/how comprehensively you can fix this in the runtime.

[AndyAyersMS]

Now that we've got dynamically adjustable dictionary slots (#32270 and follow-on PRs), this is probably not worth pursuing.