JDK-8259353 : VectorReinterpretNode is incorrectly optimized out
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 16,17
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-01-07
  • Updated: 2021-01-20
  • Resolved: 2021-01-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16 JDK 17
16 b32Fixed 17Fixed
Related Reports
Relates :  
Relates :  
Description
For the following Vector API case:

  static byte[] a = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15};
  static byte[] b = new byte[16];
  static byte[] c = new byte[16];

  private static void func(boolean print) {
    ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0);
    ByteVector bv = (ByteVector)av.reinterpretShape(SPECIES_64, 0);
    bv.intoArray(b, 0);

    ByteVector cv = (ByteVector)bv.reinterpretShape(SPECIES_128, 0);
    cv.intoArray(c, 0)���
 }

It first reinterprets vector from "SPECIES_128" to "SPECIES_64" and then reinterprets back to "SPECIES_128"; The final results in array "b" and "c" are expected to be:

  b = [ 0, 1, 2, 3, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0]
  c = [ 0, 1, 2, 3, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0]

However, the current results with C2 is:
  
  b = [ 0, 1, 2, 3, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0]
  c = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]

The results in array "c" is not right which should be zeros for the higher parts. This issue happens both on x86 and aarch64 platform. 
The root cause is the incorrect optimization for "VectorReinterpretNode". See the codes below:
  
  Node* VectorReinterpretNode::Identity(PhaseGVN *phase) {
    Node* n = in(1);
    if (n->Opcode() == Op_VectorReinterpret) {
      if (Type::cmp(bottom_type(), n->in(1)->bottom_type()) == 0) {
        return n->in(1);
      }
    }
    return this;
  }

The node will be optimized out if the bottom_type is equal to it's input's input's bottom_type. This is right if there is no truncation happens during the whole process. Otherwise, the above issue happens if there is truncation.
Comments
verified w/ the attached test. JDK-8259757 was filed to add the test.
14-01-2021

Changeset: 1cf2378b Author: Xiaohong Gong <xgong@openjdk.org> Committer: Ningsheng Jian <njian@openjdk.org> Date: 2021-01-13 05:48:08 +0000 URL: https://git.openjdk.java.net/jdk16/commit/1cf2378b
13-01-2021

Yes, this can be integrated until RDP 2 next week (2021/01/14) [1] or after that with approval and will be forward ported to JDK 17 automatically. [1] https://openjdk.java.net/projects/jdk/16/
07-01-2021

ILW = Incorrect execution of C2 compiled code, with vector API, disable compilation of affected method = HMM = P2
07-01-2021

Yeah, I want to fix this for JDK 16 if it is allowable. So fixings for JDK 16 will also be merged to the master in future, isn't it? If so, I plan to fix this for JDK 16 only.
07-01-2021

Thanks, do you plan to fix this for JDK 16?
07-01-2021

Yes, I'm sorry about it. I have found this error and tried to fix it. Maybe I forgot to save the modification. Thanks for the reminding! I'v corrected it.
07-01-2021

[~xgong] the expected and actual results in your description are equal. Copy paste error?
07-01-2021