[vector] Vector API -- alignment with value types

[Viswanathan, Sandhya]

Hi All,

Please find below a webrev applying Brian's zero patch to the tip along with the generated sources. 

http://cr.openjdk.java.net/~sviswanathan/vectorIntrinsics/Brian/zero/webrev.00/

This webrev also has a little of additional changes to take care of modifications to reinterpret code which was added later and also to the files in benchmark directory to cater to new specification of API.
Majority of the work is from Brian. The overall spirit as Brian mentioned in his email below is to simplify the Species class and move the methods to static methods on XxxVector.
With this webrev all the vector api tests on the tip continue to pass.

Looking for your feedback. 

Once again if it is ok I would like to push this on behalf of Brian and continue with API cleanup.

Best Regards,
Sandhya


-----Original Message-----
From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Brian Goetz
Sent: Wednesday, January 30, 2019 1:54 PM
To: panama-dev at openjdk.java.net
Subject: Re: [vector] Vector API -- alignment with value types

I've tried to attach the patches-in-progress for these.  There are two, the speciesFactories.patch I set recently, and then zero.patch.  These only include changes to Vector and the templates; you'll have to re-run the gen-* scripts to get changes to the rest.  They apply to the last version for which the tests pass.

Perhaps someone could look at the generated code from typical operations and see how badly this approach perturbs it?



On 1/30/2019 3:58 PM, Brian Goetz wrote:
>
>
>> Part I
>> ------
>>
>> Here's an idea for simplifying Species, which is: let's drive Species 
>> down to be a simple class that is really just a constant holder for 
>> (element type, shape), and move all the behavior to static methods on 
>> XxxVector. 
>
> I've started prototyping this, in a rather slash-and-burn manner. I am 
> about halfway through.  So far, its working, the set of changes I had 
> to make to client code is very small (almost all transforming 
> species.doSomething(args) to XxxVector.doSomething(species, args)).
>
> The question, of course, is whether the intrinsification will all 
> survive the transformation.  The most common case is that I have 
> transformed vector intrinsic calls from
>
>     VectorIntrinsic.blah(Int128Vector.class, ...)
>
> to
>
>     VectorIntrinsics.blah(species.boxType(), ...)
>
> The basic assumption is that, under the same conditions that we get 
> inlining now, we'll know the species is a constant, and boxType() will 
> just inline to a concrete box type anyway.  (The goal is to get 
> species to be values, but in the meantime, they can be enum 
> constants.)  This should work, but we'll likely have to do some JIT 
> work to get back to where we see all the inlining and 
> intrinsification.  (Much of this would come free in Valhalla.)
>
> There are a few cases where we can't just do the above, and have to do 
> a switch in the lifted method, such as:
>
> public static Shuffle<Byte> shuffle(ByteSpecies species, 
> IntUnaryOperator f) {
>     if (species.boxType() == ByteMaxVector.class)
>         return new ByteMaxVector.ByteMaxShuffle(f);
>     switch (species.bitSize()) {
>         case 64:return new Byte64Vector.Byte64Shuffle(f);
>         case 128:return new Byte128Vector.Byte128Shuffle(f);
>         case 256:return new Byte256Vector.Byte256Shuffle(f);
>         case 512:return new Byte512Vector.Byte512Shuffle(f);
>         default:throw new 
> IllegalArgumentException(Integer.toString(species.bitSize()));
>     }
> }
>
>
> Because again, species is a constant, this should also just inline 
> down to the right thing.  So far, other than reshape/rebracket, I 
> haven't seen anything requiring more complicated transformations.
>
> The only code I found so far that tries to be agnostic to shape and 
> size both is VectorResizeTest; there are strategies for making this 
> work without the combinatorial automated specialization, so I don't 
> see this as a big impediment.
>
> Where this leads to is:
>  - Vector.Species becomes an interface with a handful of methods 
> (bitSize, etc), and quite possibly one that no one uses directly;
>  - IntSpecies and friends become enums, with enum constants for I64, 
> I128, etc (or, values, with static constants for the values);
>  - The specialized classes for XxxNnVector.XxxNnSpecies _go away_;
>  - Users need not learn about species at all, but if they do care, 
> they are just simple data constants that get fed through the API.
>
> I'm not done (and am traveling the next two weeks), but I think I've 
> made progress validating the API transformation.  The real question, 
> then, is when do we do this.  I think it would be best to do before 
> previewing, simply because it is such an intrusive refactoring. But, 
> we'd have to evaluate whether we can mitigate the impact in time.
>
>