-
Enhancement
-
Resolution: Fixed
-
P4
-
9
-
b143
C2's final graph reshaping performs the following transformation:
Original pattern: LoadConP + Storage access
Transformed pattern: LoadConN + DecodeN heap-based + Storage access
This seems to be fine for simpler compressed oops mode. It also seems to be fine on x86 which can match the decoding into the operand of the Storage access instruction.
Other platforms should better skip the transformation:
-PPC can load the ConP from constant pool. Decoding takes a lot of instructions, because the heap base needs to get loaded.
(-SPARC could use that as well.)
-aarch64: LoadConN+DecodeN has a higher latency than LoadConP.
We could always skip the transformation in heap-based compressed klass mode. Matching DecodeNKlass as operand is currently not implemented.
Original pattern: LoadConP + Storage access
Transformed pattern: LoadConN + DecodeN heap-based + Storage access
This seems to be fine for simpler compressed oops mode. It also seems to be fine on x86 which can match the decoding into the operand of the Storage access instruction.
Other platforms should better skip the transformation:
-PPC can load the ConP from constant pool. Decoding takes a lot of instructions, because the heap base needs to get loaded.
(-SPARC could use that as well.)
-aarch64: LoadConN+DecodeN has a higher latency than LoadConP.
We could always skip the transformation in heap-based compressed klass mode. Matching DecodeNKlass as operand is currently not implemented.
- relates to
-
JDK-8167114 C2: Skip transformation of LoadConP for compressed oops and klass pointers
-
- Closed
-