Vector API Latest Draft Spec

[John Rose]

On Jul 14, 2017, at 1:45 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> I am unconformable with Mask pushing on expressing lanes instead of shape. Retaining shape I think requires cast like operations on Mask (at a minimum a rebracket) to make it more usable without dropping down to raw types.

I don't think Mask is a stand-alone type; it depends on Shape.

I.e., if you want a mask from me, you first have to tell me what
shape it is for.  Then I can either hand you another vector of
the same shape (for AVX2) or else a mask register (for AVX512)
or a general register (for RISC architectures like SPARC).

Given the way AVX2 works, I think masks have to be
specialized to vector size.  Given the way other platforms
work, masks have to be specialized to lane count, *but*
in practice they are boil down to subfields of the same
type of register, so lane count distinctions don't drive
register type distinctions for those platforms.

Let's call AVX2 masks vector-style masks and AVX512
and RISC masks scalar-style masks.

In this framework, vector-style masks trivially rebracket.
(At most they require a partitioned sign-extend—depends
on your conventions of sign-bit vs. all-bits for masking.
At the moment I prefer all-bits, with tweaks from late
peephole optimizations.)  Scalar-style masks require
specialized bit-doubling or bit-halving transforms to
rebracket, when their vector payloads must be
rebracketed.  But the usual case is no rebracketing
of payloads, and for that case scalar-style masks
can usually be created with the correct bracketing
(one bit per lane) using normal operations.  For
example, in SPARC/VIS, N-lane-wise comparisons can
deliver results to the low N bits of a general register.

Not sure if any of this addresses your concerns… 

— John