[vector] RFR: conversion operator fixes

[Kharbas, Kishor]

Hi John,

The patch looks good. I have two comments:
1. Since this patch throws IAE in ConversionImpl.ofCopy(), there is failure in VectorReshapeTests.java when doing castShape() with dom and range type identical.
     In other words castShape() is used for 'resize' kind of operation. Handling it specially, by calling reinterpretShape() seems to be one way to fix it.
2. Similarly ofReinterpret() will also throw IAE when 'from' and 'to' are same. We can mention this in the @throws spec.

Thanks,
Kishor

> -----Original Message-----
> From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On
> Behalf Of John Rose
> Sent: Friday, July 26, 2019 8:05 PM
> To: panama-dev at openjdk.java.net
> Subject: Re: [vector] RFR: conversion operator fixes
> 
> On Jul 25, 2019, at 4:28 PM, John Rose <john.r.rose at oracle.com> wrote:
> >
> > Ideally, the new regression test should be completed also.  It’s kind
> > of a mess right now, so I’m putting out on the side as a “bonus":
> >
> > http://cr.openjdk.java.net/~jrose/vectors/conversion-fixes/OperatorCen
> > susTest.java
> > <http://cr.openjdk.java.net/~jrose/vectors/conversion-fixes/OperatorCe
> > nsusTest.java>
> 
> More notes on that test thingy:
> 
> This is an unfinished attempt to build an independent interpreter, called
> interpretOp, that accepts any VectorOperator constant and performs a
> single-lane operation on some scalar values (boxed in a varargs list of
> Objects).  It's not for production use, just testing.
> 
> There’s also a separate interpreter called executeOp which takes one or
> more vectors populated with test values and runs the actual vector method
> (`lanewise`, `compare`, etc.) over the operator, returning the vector result.
> 
> If the scalar interpreter doesn't understand an operator, it makes a side-call
> (interpretOpViaVector) to the vector interpreter.  When the test is
> completed, this is not needed.  Instead, it should be an error if the scalar
> interpreter can't perform an operation.  The test harness should generate
> test vectors (literal vectors!) and run them through executeOp, then go back
> and re-derive each lane value using interpretOp, and make sure everything
> matches up OK.
> 
> As a side effect, this test will validate the operatorName property of vector
> operators, and (indirectly) validate the javadoc.  If we lie and say that ADD
> has an operatorName of "*", the test harness will catch it.  The overall effect
> will be to make the documentation more trustworthy.
> 
> Another thing I'd like this test harness to do is walk over the standard classes
> (Long, Float, Math) and see what static methods are available that match the
> signatures of (potential) vector operators, and print diagnostics if static
> methods are found that don't correspond to vector operations.  The scalar
> interpreter should also use the results of this search, in the case where the
> operatorName is a string like "abs" or "hypot".  It should verify what the
> javadoc claims, that an operator with such a name behaves like an
> overloaded invocation of the name in the presence of a set of static imports,
> of the "usual suspects".
> 
> Finally, I'd like to add reverseBytes and reverseBits to the set of vector
> operators.  This "census" test in part originates from me asking myself what
> other juicy operators we might have missed.