Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8330991

C2 SuperWord: refactor VPointer

XMLWordPrintable

      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.

            epeter Emanuel Peter
            epeter Emanuel Peter
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: