On generalizing vector intrinsics

[John Rose]

On Nov 14, 2017, at 5:57 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> The downside is that it requires additional non-trivial steps to find exact vector box class (see get_exact_klass_for_vector_box() and ctx->find_klass(vector_klass_name) there): the fact that vector classes aren't part of java.base, but jdk.incubator.vector complicates class lookup a bit.

I don't like (3) because it seems to extract information from context,
not from the actual call.  I'd rather be able to document the call's
semantics in terms of arguments, not contextual types.

The trade-off between (1) and (2) might be between how easy
it is to extract the implicit data from the explicit data.  Does the
intrinsic need access to all three of (a) vector size, (b) lane type,
and (c) vector class or shape?  In that case, both options leave
some info implicit and other info explicit.

If so, consider (4) passing all needed data directly and explicitly
as explicit arguments:

   (Int256Vector) VectorIntrinsics.binaryOp(VECTOR_OP_ADD,
                                            Int256Vector.class,
                                            VECTOR_ELEM_INT,
                                            256,
                                            this,
                                            (Int256Vector)o);

Then there is no behind-the-scenes decoding or lookup.

Or you might refactor as the equivalent (relying on constant folding):

   (Int256Vector) VectorIntrinsics.binaryOp(VECTOR_OP_ADD,
                                            this.getClass(),
                                            this.shape().laneTypeCode(),
                                            this.shape().bitSize(),
                                            this,
                                            (Int256Vector)o);

If it is a choice between (1) and (2) I think I prefer (2) as you do,
because it is probably easier to derive lane type and bit-size from
the concrete class than vice versa.  I am not super comfortable with
the existence of get_exact_klass_for_vector_box; it seems fragile.

Great work!  This will cut down the degrees of freedom greatly.

— John

P.S. I wonder if "saturating" is a modifier bit to add to operation codes.
Maybe "unsigned" vs. "signed" vs. "float" vs. various "fixN" are also.

I also wonder if lane type factors into lane size and arithmetic format,
so that the interesting information about the vector op breaks apart
into five parts:  1. vector size (256), 2. lane size (32), 3. lane type (int),
4. basic op (+), 5. op flags (unsigned, sat).  In that case, there is
probably an omnibus encoding that fits in one sparse 64-bit descriptor,
or even (with log-scales) a 32-bit one.  Just a thought.