RFR: 8342692: C2: long counted loop/long range checks: don't create loop-nest for short running loops [v6]

[Roland Westrelin]

On Wed, 11 Dec 2024 18:33:03 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I'm worried this solution will be susceptible to profile pollution, i.e. if a loop is called from 2 places, one with a large trip count and one with a small trip count, then the caller with a small trip count will suffer. As a result, in addition to this, making loop nests with 1 iteration of the outer loop cheaper will also be necessary. Profile pollution seems to be an issue that leads to [JDK-8307084](https://bugs.openjdk.org/browse/JDK-8307084), too.

With the current patch, a loop is short running if it has fewer than `ShortLoopIter` because restricting the number of iterations that much makes the outer strip mined loop go away as well. We could give up on that and consider that all loops that run for no more than roughly `max_jint/max RC scale` is short running. That would realistically cover a lot of loops (loops with millions of iterations that is most of them?) and would help mitigate that problem. 

I'm also looking at ways to make range checks (once hoisted out of loop by predication) cheaper to compute as the current RC expressions end up being quite convoluted. 

Do you have anything in mind?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21630#issuecomment-2538327199