RFR(L): Vector API Compare Intrinsics

[Paul Sandoz]

> On Mar 9, 2018, at 6:24 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Mar 9, 2018, at 10:51 AM, Lupusoru, Razvan A <razvan.a.lupusoru at intel.com <mailto:razvan.a.lupusoru at intel.com>> wrote:
>> 
>> Instead of "toArray" on masks, what do you think of replacing/adding "intoArray"? That way we can also intrinsify that easily without making the creation of array part of semantics.
> 
> I wonder if it would be better to have a mask to vector conversion.
> That seems to be useful in its own right, and a shorter conceptual
> distance, than a direct intoArray.  Then the vector can do the intoArray.
> 

We already have a Mask.toVector method, which i think does what you want, since the result is not a packed set of bits. It transforms the information, setting just one bit for each lane for each true bit, so the result is more like how masks on x86 are represented prior to there being the opmask registers.

The boolean[] constructing (on species, via constantMask, perhaps should be renamed) and producing are rather convenient and are a “natural" thing to reach for, although not particular space efficient compared to packed bits in longs. I cannot recall for x86 masks representations if it's LSB or MSB, but in effect the layout in HotSpot data is like a mask representation for Vector<Byte, ?>, so i can see the potential for optimizing.

Perhaps we should also provide to/from a long[] with a given bit offset?

Paul.

> It seems to me that the usual representations of masks as either
> vectors (themselves) or special vector-associated registers lead
> to two natural abstract methods, one for converting a mask to a
> vector, and one for converting it to a packed bitmask.  The latter
> peaks at 64 lanes, but that's enough for most uses today.
>