-
Enhancement
-
Resolution: Unresolved
-
P4
-
23
I have seen a few examples now, where we could know that the invar of two VPointer is identical: the same summands are added up, only in a different order. This means that the invar nodes are not identical. Somtimes there are CastLL between the additions, which further compilcates the comparison.
I suggest that we recompute the invar for each VPointer as follows:
take the invar, and traverse all AddP, AddL and CastLL nodes, to find all summands. Then sort the summands by their idx. Then add these up with new AddL nodes. If two VPointer have the same summands, then the sorted list is identical, and the result of the addition with new AddL nodes is also identical. Thus, the final invar can be relied upon to be invariant (no pun intended) to the addition order.
This optimization seems to be relevant for MemorySegment, where we work with varhandles, which seem to sometimes have different addition orders, or only sometimes have CastLL and sometimes not.
I suggest that we recompute the invar for each VPointer as follows:
take the invar, and traverse all AddP, AddL and CastLL nodes, to find all summands. Then sort the summands by their idx. Then add these up with new AddL nodes. If two VPointer have the same summands, then the sorted list is identical, and the result of the addition with new AddL nodes is also identical. Thus, the final invar can be relied upon to be invariant (no pun intended) to the addition order.
This optimization seems to be relevant for MemorySegment, where we work with varhandles, which seem to sometimes have different addition orders, or only sometimes have CastLL and sometimes not.
- relates to
-
JDK-8330991 C2 SuperWord: refactor VPointer
- Open
- links to
-
Review openjdk/jdk/18795