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

[vector] Vector API should not bake in power-of-two size assumptions

    Details

      Description

      The Vector API is designed to be portable to a reasonable range of vector hardware. The current Vector API, both in design and implementation, makes an assumption that vectors come only in power-of-two sizes and lane counts up to 128. These assumptions must be removed if the Vector API is to be portable to other platforms such as SVE.

      This work should be done before programmers inadvertently "bake in" the assumption in their own code that uses the Vector API.

      Work items:

      - Loop control (examples and API) must not invite or require the user to use POT-specific idioms such as `a.length & ~(s.length()-1)`. A properly specified `loopBound` method is needed, making proper use of `Math.floorMod`.

      - Shuffle processing of out-of-range lane indexes must not appeal to bitwise truncation. One of three responses makes sense, on a case-by-case basis, to out-of-range lane indexes: 1. `Math.floorMod` is used to extract a valid lane index (range 0..VLENGTH-1), 2. a non-existent lane is filled with a default value (zero), 3. an error is thrown. Note that `floorMod` not `%` is the correct generalization of bit-field truncation to non-POT VLENGTH.

      - Shuffle backing store must not rely only on bytes, which can only represent lane indexes up to 127 (or 255, with probable sign extension bugs). Shuffle backing store should be either full `int` values, or else values of a size hidden in the abstraction, reporting a sentinel value (-1 is preferable) for out-of-range values.

      - The package-info should not guarantee only POT sizes. The "max length" shape should not be assumed to be a power of two lanes.

      - Conversions between shuffles and vectors should properly handle out-of-range indexes, converting them to the sentinel value (-1) or else reducing modulo the number of lanes.

      - The documentation for the species attribute of shuffles should be careful to specify that a shuffle's species does not necessarily endow the shuffle with the same shape as the vectors of that species. (The definition of a shuffle's shape should be left abstract and inaccessible.)

      - When converting a shuffle of very many lanes over a very narrow type (such as a `ByteMaxVector` with more than 256 lanes), the resulting vector must have a type which can carry the required number of values (VLENGTH + 1 values, including -1 for a sentinel, if modulo reduction is not in the design). Thus, `Shuffle::toVector` might produce `Vector<Short>` not `Vector<E>`, because `E` might be insufficient to express the lane indexes.




        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              jrose John Rose
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: