is it time fully optimize long loops? (JDK-8223051)

[John Rose]

I see that strip mining [1] is pretty mature now.
I think this may open up new options for dealing with
an RFE for 64-bit iteration variables [2], specifically
using some combination of predication and/or strip
mining for strength-reducing 64-bit-tripcount loops
into one or more 32-bit-tripcount loops.

Because Project Panama works on loops over native
addresses, and is attempting to produce code that is
competitive with C code, it is necessary that Panama
code uses 64-bit iteration variables (“long loops”),
but it also expects that such loops get optimized fully,
including (but not limited to) iteration range splitting,
predication, unswitching (e.g., of type tests), and
escape analysis.

Some of this stuff works best (or only works) with
32-bit iteration variables (we can call them “short
loops”, can’t we?).  To get good performance today,
Panama library code sometimes has to perform
predication or strip mining manually, in Java code,
but this is risky (like any premature optimization)
because it makes the intention of the code more
obscure to the real optimizer, such as C2.  When we
get long loops fully supported, Panama’s performance
model will get more reliable.  But for now, Panama
is making uncomfortable compromises (e.g., [3]).

Getting the whole story working well, especially for
explicitly vectorized loops, may require new intrinsics
(such as [4]), but I think we can make progress with strip
mining or predication alone.  Is now a good time to
investigate this?

— John

[1] https://bugs.openjdk.java.net/browse/JDK-8186027
[2] https://bugs.openjdk.java.net/browse/JDK-8223051
[3] https://mail.openjdk.java.net/pipermail/panama-dev/2020-April/008411.html
[4] https://bugs.openjdk.java.net/browse/JDK-8221358