As part of a previous fix [1] for JDK-8248552, the following change was tested which allows the already narrowed type of induction variable phis before pre/main/post loops to be kept afterwards in pre/main/post loops:

--- old/src/hotspot/share/opto/cfgnode.cpp 2020-07-15 11:49:41.047714560 +0200
+++ new/src/hotspot/share/opto/cfgnode.cpp 2020-07-15 11:49:40.611529333 +0200
@@ -1080,9 +1080,9 @@
           if (bt != BoolTest::ne) {
             if (stride_t->_hi < 0) { // Down-counter loop
               swap(lo, hi);
- return TypeInt::make(MIN2(lo->_lo, hi->_lo) , hi->_hi, 3);
+ return TypeInt::make(MIN2(lo->_lo, hi->_lo) , hi->_hi, 3)->filter_speculative(_type);
             } else if (stride_t->_lo >= 0) {
- return TypeInt::make(lo->_lo, MAX2(lo->_hi, hi->_hi), 3);
+ return TypeInt::make(lo->_lo, MAX2(lo->_hi, hi->_hi), 3)->filter_speculative(_type);
             }

The type of iv phis before creating pre/main/post loops is currently lost afterwards. It should be beneficial to do the above type narrowing, especially when this type information can be propagated in the loop.

However, when doing performance evaluation, the micros open crypto benchmark openjdk.bench.javax.crypto.small.SecureRandomBench.nextBytes (located at test/micro/org/openjdk/bench/javax/crypto/small/SecureRandomBench.java) results in a repeatable regression of 1-2% with these two settings:
- algorithm=SHA1PRNG-dataSize:64-provider:-shared:false
- algorithm=SHA1PRNG-dataSize:64-provider:-shared:true

This enhancement should investigate further and show that this change could be beneficial. It should also tackle the two regressions above and try to fix those based on the suggested fix for PhiNode::Value(). Maybe there is another issue which blocks further optimizations compared to mainline.


[1] http://cr.openjdk.java.net/~chagedorn/8248552/webrev.02/