[vectorIntrinsics] reinterpret vs. reshape vs. cast

[John Rose]

My very first example was wrong.  Casts create too-large logical
outputs when their lane size expands from smaller to larger.

Editing:

Methods which squeeze require a non-negative part parameter and
are the following:

* cast, expanding a smaller lane size to a larger lane size
* reshape or reinterpret, from a larger to a smaller shape (logical output is just the input bits)
* unpack operations, which expand smaller lanes to (zero- or sign-filled) larger lanes
* data driven expansion operations (APL expand)
* zip or shuffle instructions, which interleave lanes from two (or more) vectors (logical output is the whole zip)
* shift lanes (if viewed as producing a double-sized output)
* (maybe) scatter or gather, when the payload lane (byte/short/int) is smaller than the index lane (int/long)
* other two-input operations which consolidate results into one same-shape input (merge sort step?)

GIven that unpack and expand operations are both on this list, it would
be reasonable to use a standard term instead of "squeeze" to describe
all of them, since the standard term wouldn't cause confusion.

It would be reasonable call all of the above operations "expansions"
and to observe that all such "expansions" require (for one reason or
another) a part number to select which part of the logical output to
deliver into the physical output.

Unsqueezing methods are:

* cast, from a larger lane size down to a smaller lane size
* reshape or reinterpret, from a smaller to a larger shape (logical output is just the input bits)
* pack operations, which truncate larger lanes to (zero- or sign-filled) larger lanes
* data driven compression operations (APL compress)
* (maybe) unzip or unshuffle instructions, which extract interleaved lanes back out to two (or more) vectors
* (maybe) scatter or gather, when the payload lane (double) is larger than the index lane (int)

As an antonym to "expansion" it would be reasonable to call all
of these "contractions".  A contraction always leaves empty lanes
in its physical output, because the logical output is smaller.  In
some use cases, a special part number is helpful to steer the
logical output into a specific blocks of the physical output other
than the first block.  (Which use cases?  Well, the use cases where
the various results are merged together to fill up a whole vector.
Or, other use cases where a following expansion is expected to
pick up the input bits from a location in the physical vector
that is not at the beginning.)

Anyway, so if we don't like the novelty and colloquialism of
 "squeeze" and "unsqueeze" we could use the terms "expand"
and "contract".

BTW, most operations neither expand nor contract, but produce
a logical result that exactly fits into the physical result container.
Such operations need no part numbers or parital result steering.
I suppose they could be called "in-place" or "size invariant".
I can't think of a snappy term for this yet.

— John