For example, the loop in method Fit from benchmark Puzzle gets rejected as too costly, causing loop hoisting etc. not to run on it, but it's a good candidate for such optimizations and Jit64 performed them on it:

 private bool Fit(int i, int j) { for (int k = 0; k <= _pieceMax[i]; k++) { if (_p[i][k]) { if (_puzzle[j + k]) { return false; } } } return true; }

There's already special consideration for loop conditions that involve shared static helpers; maybe similar treatment should be applied to loop conditions involving arrLen operators.

In this particular case, getting past the heuristic would enable hoisting the load of _p and the sign extension of i from the loop, but hoisting more of _p[i] (like the length of _p, the bounds-check, and/or the whole load) is blocked by #6554.

category:cq
theme:loop-opt
skill-level:expert
cost:medium