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
For example, the loop in method
Fitfrom 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:There's already special consideration for loop conditions that involve shared static helpers; maybe similar treatment should be applied to loop conditions involving
arrLenoperators.In this particular case, getting past the heuristic would enable hoisting the load of
_pand the sign extension ofifrom 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