Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8250607

C2: Filter type in PhiNode::Value() for induction variables of trip-counted integer loops

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Fixed
    • P4
    • 16
    • 16
    • hotspot
    • b25

    Description

      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/

      Attachments

        Issue Links

          Activity

            People

              roland Roland Westrelin
              chagedorn Christian Hagedorn
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: