Recently, I have looked more deeply into VPointer, and found a few limitations. The parsing code is rather convoluted and difficult to reason about and extend.

I propose to do a design like this:
First have an up-traversal that finds all nodes that are part of the address. Then, have an "echo"-traversal down, where each node determines its address form, either based on this exact node, or the combination of the forms of the input nodes.


Related issues:
JDK-8326962 -> the VPointer are computed ahead of time and cached
JDK-8330819 -> bug, have to disable vectorization in some cases - could be recovered if we parse not just through AddP, but also CastX2P and AddL.
JDK-8330274 -> generalization of the invar parsing, could be integrated into the parsing, rather than doing the decomposition and sorting of the invar at the end.

I would also like to consider removing the "adr" field, which is currently used for non-array accesses, where the "base == TOP". I don't see the benefit of having a separate "adr", which essentially has the same constraints as the "invar" already has. It must be a loop independent long, which may or may not be aligned.