[vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore"

[John Rose]

On Sep 3, 2021, at 1:11 PM, Paul Sandoz <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>> wrote:

...
John, your observation on order really stood out to me. I can see how a prefix-sum might behave with a mask describing the selection of lanes *and* compression of the result (no intermediate values, either from the input or zero).

Yes, this whole thread is a very good exercise in what we
call “find the primitive”.  Which means taking some use
cases, and some hardware capabilities, and some known
optimization techniques, and deciding how to factor
down the use cases into uses of the latter capabilities and
techniques, such that (a) the use cases are well optimized
and (b) a naturally wide set of future use cases are supported.

(And by “naturally” I mean the chose primitives directly
give access to the capabilities and techniques, so that
it is new use cases “grow out of” the existing primitives
without additional deep insights.)


In summary, from the discussion, compress/expand are:

- important conceptually, even if the same functionality could be composed from shuffles (such as used by an implementation); and

Compression can be composed from *colliding* shuffles,
which are a special kind of thing I call an anti-shuffle.
I suspect *that* is the really interesting primitive here.


- at the right level to reliably optimize on supporting hardware.

So specification-wise we introduce expanding/compressing cross-lane operations. API-wise I prefer two distinct methods rather that one that accepts boolean indicating expansion or compression. We can declare one intrinsic method in VectorSupport.

Yes, a function and its inverse are usually not best accessed
by a boolean option that says “select the inverse”.  Partly
this is because the edge effects and exceptions (such as
collisions for anti-shuffle but not shuffle) make the types
of the function and its inverse subtly different.