[vector] RFR: conversion operator fixes

[John Rose]

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/OperatorCensusTest.java <http://cr.openjdk.java.net/~jrose/vectors/conversion-fixes/OperatorCensusTest.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.