Details

    • Type: Sub-task
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
      None

      Description

      There are three forms of resizing operations:

      1) Vector.resize
      2) Vector.cast
      3) Mask/Shuffle.cast

      All these operations can result in a change of shape and therefore vector size, and when vector size changes we need to specify what happens when the size greater or smaller and rubs up against the limits of the smallest and largest supported vector size.

      If there exists only one vector shape, such as for ARM SVE, these methods may be ill-defined or less applicable.

      For example, on x86, given a ByteVector<Shapes.S512Bit>, containing 64 byte elements and vector lanes, it is not possible to cast to an equivalent IntVector<S>, for some shape S containing 64 int elements. We have to limit to an IntVector containing 16 int elements converted from 16 byte elements selected from the ByteVector.

      At the moment the cast operation is restricted to only support casting to vectors with the same number of lanes. It is first necessary to resize the input vector to the appropriate size (and number of lanes) to perform the cast, such as in the following example calculating a hash of bytes:

                  for (int j = 0; j < byteSpecies.length() / intSpecies.length(); j++) {
                      ByteVector<S> b = byteSpecies.fromArray(a, i);
                      // Reduce the size of the byte vector and then cast to int
                      IntVector<S> x = intSpecies.cast(bytesForIntsSpecies.resize(b));

                      h = h * top_h_coeff + x.mul(v_h_coeff).addAll();

                      b = b.shiftEL(intSpecies.length());
                  }
         
      In this example both the byte and int vector have the same shape, but before the cast is performed the byte vector has to be reduced in size to contain the same number of lanes as the int vector. Notice at the end of the loop the byte vector elements are shifted left by the number of int vector lanes so the next next prefix of bytes can be cast,

      We may need to revert the cast behaviour to take the prefix of elements from the input vector (for a smaller number of lanes) or fill in default values in the resulting vector (for larger number of lanes e.g. a cast back from an int vector to a byte vector). This would ensure cast is applicable in single shape cases.

      Resizing is redundant when only one shape exists. A mask could be used to define a prefix of elements, or control how to compress a vector, before casting. A compress operation could be composed from the binary rearrangement operation accepting a shuffle and a mask. The shuffle needs to be derived from compressing mask lanes that are set, and another mask needs to be derived from the compressing mask with a prefix of set lanes whose length that is the input mask set count.

      This implies we are missing a compress operation and/or missing some useful transformation operations between mask and shuffle and between mask and mask.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              psandoz Paul Sandoz
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: