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

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 16
    • Fix Version/s: 16
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      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

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

                Dates

                Created:
                Updated:
                Resolved: