[vector] Prototype of apply() method on Vector

[Brian Goetz]

This is a nice start!  Thanks for plumbing it through for at least one 
op, and verifying the resulting code.  As far as I can see, you add two 
vectors with

     v3 = v1.op(BOp.ADD, v2)

It is encouraging to see that this doesn't affect our ability to inline 
deep enough to generate good code.

This technique has two main benefits:

  - Reduces the API surface, by allowing operations like ADD to support 
all the addable types of vectors, rather than having N add methods
  - Enabling the building of higher-level operations that can deal with 
the "tail" computation.

The latter is where I see the major value; vectorized APIs won't want to 
expose vectors, they'll want to let users pass in arrays of values and 
do vectorized operations over them.  Because the array size may not be 
an integral multiple of the lane count, there may be a "tail" of values 
that have to be computed "the old fashioned way".  And that's not the 
really bad part; the really bad part is that the main vectorized loop 
and the "tail" loop will spell "add" differently from each other.  And 
having two ways to say the same thing is a bug waiting to happen.

Rewriting

             av.mul(av)
                     .add(bv.mul(bv))
                     .neg()
                     .intoArray(c, i);

to

             av.apply(BOp.MUL, av)
                     .apply(BOp.ADD, bv.apply(BOp.MUL, bv))
                     .apply(UOp.NEG)
                     .intoArray(c, i);

is not going to be the user's first choice, but may be tolerable (especially if we view this library as a low-level tool for others to build higher-level vectorized operations atop.)

I see this approach as meeting up with the other main API discussion direction, which is: positioning the key abstractions (species, vectors) to be ready to be values as soon as Valhalla is ready.  This will have some effect on the API, such as flattening out class inheritance; I suspect these two transformations will interact nontrivially (maybe in a good way, maybe not.)

Where I would say we are is:

  - It's really great that we prototyped this, and discovered that this transformation of the code is not, in itself, an impediment to efficient compilation;
  - It promises a way out of the "tail loop" problem;
  - It might be something users can live with;
  - Let's set it on the shelf for a bit, and let the value-ification of the API play out a bit more, and look back at this.

Does that sound like a good plan?

On 2/16/2019 7:02 PM, Kharbas, Kishor wrote:
> Hi Brian, John, Vladimir and others,
> There has been discussion on this mail thread before (did not find the mail thread to reply to it) about having an apply() on vectors.
>
> The idea is to reduce the api surface by defining a apply() method which takes the kind of operation to be performed. Here is an attempt to prototype this method,
> http://cr.openjdk.java.net/~kkharbas/vector-api/webrev-apply.00
>
> This prototype does generate optimal vector code just like operation specific methods.
>
> Please let me know your thoughts.
>
> Thanks,
> Kishor